© 2013 - 2014 帕特里克·库阿

目录

Table of Contents

• 前言
• Foreword
• 前言
  • 我为什么写这本书
  • 你会在这本书中找到什么
• Preface
  • Why I wrote this book
  • What you’ll find in this book
• 致谢
• Acknowledgements
• 感言
• Testimonials
• 介绍
  • 在一开始的时候
  • 从 Tech Lead 到 Tech Lead
  • 从新手到实践者
• Introduction
  • In the Beginning
  • From Tech Leads to Tech Leads
  • From Novices to Practitioners
• 新手
  • 不同的视角——Cameron Swords
  • 焦点的改变——安妮·西蒙斯
  • 需要更广泛的技能——Ebony Pierce
  • 杂耍表演——Siebert Lubbe
  • 外部面孔——Liz Douglass
  • 混乱与无能——罗伊·奥舍罗夫
  • 不仅仅是技术 – Priyank Gupta
  • 更大的图景——Suchit Puri
  • 更少的编码，更多的责任——David 'Bucky' Schwarz
  • 依靠沟通技巧——Stefan Marev
• Novices
  • A Different Perspective – Cameron Swords
  • Change of Focus – Anne Simmons
  • Needs for a Wider Skill Set – Ebony Pierce
  • Juggling Act – Siebert Lubbe
  • The External Face – Liz Douglass
  • Chaos and Cluelessness – Roy Osherove
  • More Than Just Tech – Priyank Gupta
  • The Bigger Picture – Suchit Puri
  • Less Coding, More Responsibility – David ‘Bucky’ Schwarz
  • Lean on Communication Skills – Stefan Marev
• 从业者
• Practitioners
• 人们
  • 团队焦点——艾莉森·罗斯沃恩
  • 团队超越自我——汉弗莱·埃尔顿
  • 代表，代表，代表——杰森·塞尔比
  • 促进，然后领导——丹·阿贝尔
  • 帮助团队——亚当·埃斯特林
  • 向内和向外——雷切尔·莱科克
  • 软技能——乔恩·皮瑟
  • 赋能人——伊莎贝拉·德根
  • 这与代码无关——Patric Fornasier
  • 以人为本——Sarah Taraporewalla
  • 参与团队——格伦·福特
• People
  • Team Focus – Alison Rosewarne
  • Team over Self – Humphrey Elton
  • Delegate, Delegate, Delegate – Jason Selby
  • Facilitating, then Leading – Dan Abel
  • Helping the Team – Adam Esterline
  • Inwards and Outwards – Rachel Laycock
  • Soft Skills – Jon Pither
  • Enabling People – Isabella Degen
  • It’s Not About the Code – Patric Fornasier
  • People Focus – Sarah Taraporewalla
  • Engaging the Team – Glen Ford
• 技术主管的技术
  • 团队和架构——Simon Brown
  • 实现和解决方案设计——Marten Gustafson
  • 管理技术债务——Mark Crossfield
  • 也是建筑师？– 托米瓦内克
  • 冠军品质——彼得·莫兰
  • 不要忘记跨职能需求——Christy Allmon
  • 优先处理技术任务——Chris Close
• The Tech of a Tech Lead
  • Teams and Architecture – Simon Brown
  • Enablement and Solution Design – Marten Gustafson
  • Manage Tech Debt – Mark Crossfield
  • An Architect Too? – Tomi Vanek
  • Champion Quality – Peter Moran
  • Don’t Forget Cross-Functional Requirements – Christy Allmon
  • Prioritising Tech Tasks – Chris Close
• 将业务与技术联系起来
  • 大局——卢卡·格鲁拉
  • 使技术与业务保持一致——Robert Annett
  • 描绘未来——杰森·丹尼斯
  • 在业务中找到平衡——Cory Foy
  • 通往商业的桥梁——Ryan Kinderman
• Bridging the Business with Tech
  • The Big Picture – Luca Grulla
  • Align Technology with Business – Robert Annett
  • Mapping the Future – Jason Dennis
  • Finding Balance with the Business – Cory Foy
  • A Bridge to the Business – Ryan Kinderman
• 你
  • 管理自己——斯蒂芬·哈迪斯蒂
  • 侦察——杰弗里·吉斯曼
  • 从后面领先——乔尔·托西
  • 了解自己——丹尼尔·沃辛顿-博达特
  • 寻找平衡——劳拉·帕特森
• You
  • Managing Yourself – Stephen Hardisty
  • Scouting – Geoffrey Giesemann
  • Lead from Behind – Joel Tosi
  • Understand Yourself – Daniel Worthington-Bodart
  • Finding Balance – Laura Paterson
• 结论
  • 新任技术主管的经验教训
  • 实践技术主管的经验教训
  • 最后的话
• Conclusions
  • Lessons Learned by First-Time Tech Leads
  • Lessons Learned by Practising Tech Leads
  • Final Words
• 附录
  • 有用的书
  • 有用的网站
  • 其他参考资料
• Appendix
  • Useful Books
  • Useful Websites
  • Other References
• 关于作者
• About the Author

前言

Foreword

作者：Neo4j 首席科学家 Jim Webber

http://jimwebber.org

@jimwebber

By Jim Webber, Chief Scientist, Neo4j

http://jimwebber.org

@jimwebber

当帕特里克找我写这篇前言时，我有点犹豫。我不是特别出名——甚至作为技术主管也不是！但读完这本书后，我开始理解为什么帕特里克相信我会发现这本书值得贡献一点。

When Patrick approached me to write this foreword, I was a little hesitant. I’m not especially renowned – not even as a Tech Lead! But after I read the book, I began to understand why Patrick believed I’d find the book worthy of a small contribution.

这是一本重要的书，它对软件的软性方面做出了重大贡献：对高级软件工程师意味着什么这个问题，开启了经验性的反思之路。此外，在“与 Tech Leads 交谈”中，Patrick 获得了关于承担 Tech Lead 职责意味着什么的各种经验、观点和反思，远远超出了“仅仅”能够胜任软件交付的范围。

This is an important book and it makes a substantial contribution to the soft side of software: namely one that begins a path towards empirical reflection on what it means to be a senior software engineer. Moreover, in “Talking with Tech Leads” Patrick has captured a wide variety of experiences, opinions, and reflections on what it means to bear the responsibilities of a Tech Lead, far beyond “merely” being competent at software delivery.

揭示 Tech Leads 的实践、情绪和抱负，以及他们的疑虑、不确定性和磨难，是从经验上确定角色的性质和期望的宝贵的第一步。在采取这一步骤时，它使新的 Tech Lead 能够管理自己的期望（和神经），而经验丰富的 Tech Lead 通过了解他们的同行如何解决（或未能解决）困扰他人的挑战来成长。

Uncovering the practices, emotions, and ambitions of Tech Leads as well as their doubts, uncertainties and tribulations is a valuable first step towards empirically qualifying the nature and expectations of the role. In taking that step, it enables the new Tech Lead to manage their own expectations (and nerves) and the seasoned Tech Lead to grow through understanding how their peers have solved (or failed to solve) the challenges that beset others.

这不是一本职业指导书，甚至也不是一本自助书，尽管我认为这两本书都可以作为阅读和内化访谈的副作用来适当解决。当您不确定是否要进入或扩展您作为 Tech Lead 的角色时，可以参考这本书。根据受访者的性质，它提供了一种直接的社区感、全球性和多样性。他们的故事之所以能引起共鸣，正是因为它们是来自有代表性的技术专家的诚实陈述，就像读者一样。所有内容都经过精心编目和策划，以吸引人并提供可方便地映射到典型职业弧线的总体叙述。

This is not a career guidance book, or even a self-help book, though both I think are suitably addressed as a side-effect of reading and internalising the interviews. This is a book that you can turn to when you’re feeling unsure about moving into, or expanding your role as a Tech Lead. It provides an immediate sense of community, global and diverse, by the nature of the interviewees. Their stories resonate precisely because they’re honest accounts from representative technologists, much like you, the reader. All are well catalogued and curated to be engaging and provide an overarching narrative that maps conveniently to a typical career arc.

我希望像大多数软件人员一样，通常我阅读技术著作的次数要多于阅读经验报告的次数。“与 Tech Leads 交谈”帮助我纠正了一些这种平衡，并思考了在 21 世纪初领导软件团队意味着什么。为此，我感谢帕特里克，我希望你会觉得这本书也能帮助你反思和解决你在技术领导方面的挑战和抱负。

I expect, like most software people, ordinarily I read technical works much more than I read experience reports. “Talking with Tech Leads” has helped me redress some of that balance and think through what it means to lead software teams in the early 21st century. For that I am grateful to Patrick and I hope you’ll feel that the book will help you to reflect upon, and address, your challenges and aspirations around technical leadership too.

前言

Preface

我为什么写这本书

Why I wrote this book

在 ThoughtWorks 担任软件开发顾问期间，我担任过无数次 Tech Lead 的角色。在十多年的 IT 工作中，我看到了不同的 Tech Leads 如何运作和解决他们的难题。我还在 ThoughtWorks 内部以及为与我们合作的客户培训、指导和成功培养了其他技术主管。我注意到开发人员向 Tech Lead 的转变绝非易事。即使是经验丰富的技术主管在第一次更换团队或组织时也会遇到困难。

I have played the Tech Lead role countless times, in my role as a software development consultant at ThoughtWorks. In over a decade of working in IT, I have seen how different Tech Leads operate and grapple with their difficult problems. I have also trained, coached and successfully developed other Tech Leads – both within ThoughtWorks and for the clients we work with. I noticed that the transition for a developer to a Tech Lead is never easy. Even experienced Tech Leads struggle when they first change teams or organisations.

当开发人员成为 Tech Lead 时，你会突然意识到这个角色是多么的孤独。你将不再是“只是一个开发者”，你将不再被这样对待。当您寻求支持和建议时，您会发现没有人能够理解您的独特职位、团队和背景。如果您在更大的组织工作，那么您很幸运——您身边还有其他 Tech Lead。但即便如此，你也无法轻易看出他们是如何管理团队的，更不可能看出他们是如何思考所面临的问题的。

When you, the developer, become a Tech Lead, you suddenly realise how lonely the role is. You will no longer be “just a developer,” and you will no longer be treated as such. When you look for support and advice, you find that no one can understand your unique position, team and context. If you work for a larger organisation, you are in luck – you have other Tech Leads around you. But even then, you cannot easily see how they run their teams and even less likely, how they think through the problems they face.

我开始这本书的项目是因为我看到开发人员如何努力适应 Tech Lead 头衔带来的不同技能和职责。您作为开发人员获得的经验并不能为您承担该角色的职责做好准备。与大量的编程书籍不同，很少有资源可以帮助开发人员为这个角色做好准备，或者帮助 Tech Leads 进一步发展自己。

I started this book project because I saw how developers struggled to adapt to the different skills and responsibilities that come with the Tech Lead title. The experience you gain as a developer does not prepare you for the responsibilities of the role. Unlike the bountiful number of books on programming, there are few resources that help developers prepare for this role, or help Tech Leads develop themselves further.

这本书可以帮助您成为更好的 Tech Lead。

This book helps you on your journey to becoming a better Tech Lead.

你会在这本书中找到什么

What you’ll find in this book

本书为您提供了现实生活中 Tech Leads 的经验。我希望这本书能够代表广泛的经验，并寻找在世界各地不同环境下工作的 Tech Leads。

This book offers you the experiences from real-life Tech Leads. I wanted this book to represent a wide spectrum of experiences and found Tech Leads who work all over the world in different circumstances.

一些 Tech Lead 为非常大的组织工作，而另一些则为非常小的团队工作。他们的团队在旅游、金融、房地产、媒体和咨询等行业编写软件。一些 Tech Leads 领导着一支由经验丰富的开发人员组成的团队，而另一些 Tech Leads 则领导着一支经验丰富的团队，其中包括对行业相对较新的开发人员。有了这个范围，我希望有一些人可以与你联系，也有一些新情况需要注意作为 Tech Lead 的角色。

Some Tech Lead works for very large organisations, whilst others work for very small groups. Their teams write software in industries such as travel, finance, real estate, media, and consulting. Some Tech Leads guide a team of very experienced developers, whilst others lead a team with a mix of experience, including developers relatively new to the industry. With this spectrum, I hope there are people you can relate to, and also new circumstances to be aware of in the role of a Tech Lead.

技术主管通过一系列精心策划的访谈分享他们的观点、角色以及他们如何解决问题。采访的结构有意相似，以了解不同的 Tech Leads 的反应。

The Tech Leads share their views their role and how they solve problems through a series of curated interviews. The structure of the interviews was intentionally similar, in order to see how different Tech Leads responded.

您会发现没有单一的领导开发团队的最佳方式。相反，您会发现处理 Tech Lead 角色不同方面的不同方法。

You will find that there is no single best way to lead development teams. Instead, you will discover different approaches to dealing with different aspects of the Tech Lead role.

致谢

Acknowledgements

首先，我要感谢所有的贡献者。我知道 Tech Lead 角色是多么耗时，每个人都花了很多时间来思考和写下他们对这个角色的想法。分享艰难时期的故事需要谦逊，每个人都提供了他们的经验来分享和学习。

First of all, I would like to thank all the contributors. I know how time-consuming the Tech Lead role is and it took significant number of hours for each person to think about and write down their thoughts about the role. Sharing stories about tough times requires humility and everyone offered their experiences to share and learn from.

我要特别感谢本书新手部分的贡献者。他们不仅很难找到，因为第一次成为 Tech Lead 当然只有一次，而且他们也勇于与世界分享他们的经验。

I’d like to give special thanks to contributors in the Novice section of the book. Not only were they hard to source, because being a Tech Lead for the first time happens only once of course, but they were also courageous in sharing their experiences with the world.

还要感谢无数帮助我接触到本书中人物的人。没有他们的推荐和他们给我介绍的人，我不可能传授如此广泛的经验和背景。

Thanks too to the countless people who helped put me in touch with the people included in the book. Without their recommendations and people they introduced me to, I would not have been able to pass on such a wide variety of experiences and backgrounds.

我承认内容可能有点偏颇，因为很多人都与ThoughtWorks有某种联系。这取决于我的背景和网络。我认真工作，将我的网撒得更远，试图捕捉在不同公司、行业工作并具有广泛经验的 Tech Leads。我希望作为读者的你能从中受益。

I recognise that the contents may be a little biased with many people having some connection with ThoughtWorks. This is down to my background and network. I worked conscientiously to cast my net further afield, attempting to capture Tech Leads working in a diverse set of companies, industries, and with a broad range of experiences. I hope that as a reader you benefit from this.

我还要感谢与我合作的编辑，Virtual Editor的 Angela Jameson Potts 。很高兴再次与她合作，我非常感谢她使用非传统书籍排版工具的灵活方法。

I’d also like to thank the editor I collaborated with, Angela Jameson Potts of Virtual Editor. It was a great pleasure to work with her again, and I greatly appreciated her flexible approach to working with very non-traditional book formatting tools.

最后，我要感谢您，读者：感谢您选择本书。我希望你能从中学到很多东西。

Finally, I want to acknowledge you, the reader: thank you for selecting this book. I hope you learn much from it.

感言

Testimonials

“我希望我在五年前读过这本书。它改变了我阅读后第二天的工作方式。我会把它推荐给任何新的或有抱负的 Tech Lead。”

“I wish I had read this book five years ago. It changed the way I worked the day after I read it. I would recommend it to any new or aspiring Tech Lead.”

– David Morgantini，英国政府数字服务技术主管

– David Morgantini, Tech Lead, UK Government Digital Service

“阅读《与 Tech Leads 对话》就像去参加一个会议，观看关于领导团队的精彩小组讨论。”

“Reading ‘Talking with Tech Leads’ is like going to a conference and watching a great panel discussion on leading teams.”

“这本书让我重新思考我的立场以及我与直接下属合作的方式。”

“This book has made me rethink my position and the way I work with my direct reports.”

– DRW Trading Group 技术主管 Nick Malnick

– Nick Malnick, Tech Lead, DRW Trading Group

“我喜欢建议、评论和采访的演变，以及书籍结构所产生的深度和复杂性的增加。”

“I like the evolution of advice, comments and interviews and increasing depth and complexity generated by the book structure.”

– Hugo Corbucci，ThoughtWorks 技术主管

– Hugo Corbucci, Tech Lead, ThoughtWorks

介绍

Introduction

在一开始的时候

In the Beginning

技术领导者——简称 Tech Leads——几乎都是以同样的方式开始的：程序员或软件开发人员，由于环境或时间的推移，被要求担任 Tech Lead 的角色。故事往往是这样的：

Technical Leaders – Tech Leads for short – almost all start out in the same way: a programmer or software developer, either by circumstance or through the passing of time, who is asked to take on the Tech Lead role. The story often goes something like this:

认识布赖恩。Brian 在 Zalana 担任开发人员，该公司向人力资源部门的人员销售软件即服务产品。三年前，布赖恩 (Brian) 自 Zalana 创立之初就加入了 Zalana。

Meet Brian. Brian works as a developer for Zalana, a company selling a software-as-a-service product to people who work in Human Resources. Brian has been with Zalana since its start, three years ago.

多年来，开发团队已经从只有 Brian 发展为另外三名开发人员。其他开发人员非常尊重 Brian 设计、测试和编写健壮且易于理解的代码的能力。产品经理 Sheryl 推动产品方向，当她有问题时几乎总是与 Brian 联系，因为她发现他与她的沟通很好。他特别擅长向她解释技术解决方案或约束条件。

Over the years, the development team has grown from just Brian to three other developers. The other developers really respect Brian for his ability to design, test and write robust code that is also easy to understand. Sheryl, the Product Manager, drives the product direction and almost always approaches Brian when she has questions because she finds he communicates well with her. He is particularly good at explaining technical solutions or constraints to her.

一天，Zalana 的创始人 Bob 邀请 Brian 出去吃早餐。布赖恩认为这有点不寻常，因为他知道鲍勃从不吃早餐，而且更喜欢与投资者和潜在客户共度深夜。布赖恩既好奇又有点担心，他同意在一家舒适的法国餐厅与鲍勃会面。Brian 到了，看到 Bob 在他的智能手机上阅读和回复电子邮件，然后在对面坐下。

One day, the founder of Zalana, Bob invited Brian out for breakfast. Brian thought this a little unusual because he knew Bob never ate breakfast and preferred to spend time late into the evenings with investors and potential customers. Intrigued and slightly concerned, Brian agreed to meet Bob at a cosy French restaurant. Brian arrives, sees Bob on his smartphone, reading and responding to emails, and sits down opposite.

Bob 看到 Brian 走近并放下他的智能手机。Bob 笑了笑，等 Brian 坐下才宣布，“Brian，我有一些令人振奋的消息。我们的生意做得很好。我们刚刚签了三个大客户。我知道开发团队一直在努力工作。我们确实可以看到结果，但我们需要壮大团队；如果需要，可以加倍或三倍。” Bob 停下来扫视 Brian 的脸。“我们希望你担任 Tech Lead 的角色。”

Bob sees Brian approach and puts down his smartphone. Bob smiles, waiting for Brian to sit before announcing, “Brian, I have some exciting news. Our business is doing well. We have just signed three big customers. I know the development team has been working hard. We can really see the results, but we need to grow the team; double or triple it if need be.” Bob pauses to scan Brian’s face. “We want you to take the Tech Lead role.”

Brian 的思绪在三个新客户的前景和对开发团队的新需求流以及新角色的提议上摇摆不定。问题在他脑海中闪过：为什么是我？投资者和其他企业对我有什么期望？其他开发人员会如何看待我？我还能写代码吗？

Brian’s mind is reeling at the prospect of three new customers and the fresh stream of demands on the development team, as well as the offer of a new role. Questions race through his head: Why me? What will investors and the rest of the business expect of me? How will the other developers see me? Will I still get to write code?

布赖恩知道鲍勃不耐烦但性格善良，于是回答说：“好吧，我试试看。” 但是，当 Bob 再点一杯咖啡时，Brian 看着他的菜单并想，“现在怎么办？”

Brian knows Bob’s impatient but good nature and answers, “OK, I’ll give it a go.” But, as Bob orders another coffee, Brian looks at his menu and thinks, “Now what?”

虽然这纯属虚构，但它说明了本书中许多访谈背后的教训。技术主管的角色与开发人员的角色截然不同，尽管它们在某种程度上有所重叠。然而，那些进入这个角色的人总是对其中的差异感到惊讶。像 Brian 一样，许多人发现自己是出于偶然或机会而担任 Tech Lead 的角色，只有当他们发现自己担任 Tech Lead 的角色时，他们才意识到不同的职责需要许多技能，而这些技能是在当程序员时无法培养的。

Although this is pure fiction, it illustrates the lesson underlying many of the interviews in this book. The Tech Lead role is quite distinct from the developer role, even though they overlap to some degree. However, those who move into the role are always surprised at what the differences are. Like Brian, many find themselves thrust into the role of a Tech Lead by chance or opportunity, and it was only when they found themselves in the Tech Role that they realised the different responsibilities required many skills that you don’t develop in the role of a programmer.

您花在磨练开发技能上的时间，例如查看代码中的模式、重构代码以更易于维护或扩展以及编写测试，对于解决冲突、建立团队文化或以非技术人员可以理解的特定方式交流技术的技能几乎没有帮助。

The time you spend honing your development skills, such as seeing patterns in code, refactoring code to be easier to maintain or extend, and writing tests does little to prepare skills in resolving conflict, establishing a team culture, or communicating technology in ways that non-technical people can understand.

Tech Leads 几乎总是发现自己独自工作，并且会问“我作为 Tech Lead 做的事情是否正确？” 通常很难回答。大多数开发人员都会让其他开发人员就使用哪种工具或框架征求他们的意见，或者就他们的代码的设计或可测试性获得反馈。一位 Tech Lead 很少有其他 Tech Lead 分享解决人员问题的想法，或者更有效地将紧迫的技术问题传达给业务的方法。

Tech Leads almost always find themselves working solo and the question “Am I doing the right things as a Tech Lead?” is often difficult to answer. Most developers have other developers to ask for their opinion on which tool or framework to use, or to get feedback on the design or testability of their code. A Tech Lead rarely has other Tech Leads around to share ideas on approaching people problems, or ways to more effectively communicate pressing technical matters to the business.

这组访谈提供了缺失的环节：其他人如何担任这个角色、他们面临的挑战以及不同的经历展示了人们作为 Tech Lead 以不同方式取得成功的方式。

This collection of interviews provides that missing link: how others approach the role, the challenges they have and the different experiences demonstrate the ways people succeed in different ways as a Tech Lead.

从 Tech Lead 到 Tech Lead

From Tech Leads to Tech Leads

出于本书的目的，我将 Tech Lead 定义为：

For the purposes of this book, I define a Tech Lead as:

领导者，负责开发团队，至少 30% 的时间与团队一起编写代码。

A leader, responsible for a development team, who spends at least 30 per cent of their time writing code with the team.

我觉得写一些代码是技术领导力的一个重要方面。拥有技术背景通常不足以帮助促进讨论或降低技术风险。一些组织具有技术经理、开发经理或团队负责人等角色，担任这些角色的人不编写任何代码。本书并不试图描述他们的责任或挑战。

I feel that writing some code is an important aspect of technical leadership. Having a technical background is not usually enough to help facilitate discussions or mitigate technical risk. Some organisations have roles like Technical Manager, Development Manager or Team Lead and people in these roles do not write any code. This book does not attempt to describe their responsibilities or challenges.

本书专注于为突然发现自己要处理重要但并非完全非技术性任务的软件开发人员提供建议。突然间，当被授予 Tech Lead 角色时，开发人员需要在新的非技术任务与他们熟悉的详细设计世界、解决软件问题（而不是人的问题！）和削减代码之间取得平衡。

This book focuses solely on giving advice to software developers who suddenly find themselves dealing with significantly, but not exclusively non-technical tasks. Suddenly, when given the Tech Lead role, a developer is required to balance new non-technical tasks with their familiar world of detailed design, solving software problems (not people problems!) and cutting code.

尽管很多人可以对他们认为 Tech Lead 应该做什么或应该做什么做出回应，但我想从真正的 Tech Lead 那里收集经验教训。我收录在本书中的贡献者符合两个简单的标准：

Although many people could have given responses to what they feel a Tech Lead does or should do, I wanted to collect lessons and experiences from real Tech Leads. The contributors I have included in this book match two simple criteria:

1. 他们负责一个由三个以上的开发人员组成的团队；
2. They are responsible for a team of more than three developers;
3. 他们与团队一起编写代码。
4. They write code with the team.

这两个因素排除了许多通常具有软件架构师、团队经理、开发经理、开发主管或敏捷教练等头衔的人。扮演这些角色的人可能有很好的想法和意见，但我想避免那句老话：

These two factors excluded many who would typically bear titles such as Software Architect, Team Manager, Development Manager, Head of Development, or Agile Coach. The people playing these roles may have very good ideas and opinions but I wanted to avoid the old adage:

照我说的做，而不是像我做的那样。

Do as I say, not as I do.

我不会向您提供可能未经尝试和测试的想法，而是向您提供故事和从具有现实世界经验的人那里学到的经验教训，这些人在面试时担任 Tech Lead 角色。

Rather than giving you ideas that may not have been tried and tested, I offer you stories and lessons learned from people with real world experience, people who were playing the Tech Lead role at the time of their interview.

从新手到实践者

From Novices to Practitioners

本书中的人物代表了两种观点，提供了对 Tech Lead 角色的最佳洞察。

The people in this book represent two perspectives that provide the best insight into the Tech Lead role.

• 新手- 你不会是第一个过渡到技术主管角色的开发人员。在新手部分接受采访的人分享了他们如何处理从整天编写代码到突然对一组全新的陌生任务负责和负责的转变。本节中的每个人在面试时都将自己描述为“新任技术主管”。
• Novices - You will not be the first developer to transition into the Tech Lead role. The people interviewed in the Novices section share how they deal with the transition from writing code all day, to suddenly being responsible and accountable for a whole new set of unfamiliar tasks. Each person in this section described themselves as a “first-time Tech Lead” at the time of the interviews.
• 从业者——新任 Tech Leads 会随着时间的推移迅速转变为经验丰富的 Tech Leads。虽然 Tech Lead 继续遇到他们作为开发人员没有经历过的独特情况，但他们可以利用他们以前作为 Tech Lead 处理过的其他情况。这个版块的人，往往都担任过几个团队的Tech Lead，或者担任过几年的Tech Lead。他们分享他们收集的智慧和见解，同时在这个角色中获得更多经验。
• Practitioners - First-time Tech Leads quickly transition into experienced Tech Leads in the course of time. While the Tech Lead continues to encounter unique situations they did not experience as a developer, they can draw on other situations they have dealt with previously as a Tech Lead. The people in this section have often played Tech Lead for several teams, or have played the Tech Lead for several years. They share their wisdom and insights they gleaned while gaining more experience in this role.

事实证明，寻找经验丰富的 Tech Leads 比首次担任 Tech Leads 容易得多，这两个部分之间的权重不均反映了这一点。随着经验丰富的 Tech Leads 的回复明显增多，我发现出现了几个更强烈的主题，我将这些回复分为：

Finding seasoned Tech Leads proved significantly easier than first-time Tech Leads, and the uneven weighting between the two sections reflects that. With significantly more responses from seasoned Tech Leads, I found several stronger themes emerged and I grouped the responses into:

1. 人——专注于 Tech Lead 角色所需的软技能。
2. People – Focuses on the softer skills required by the role of Tech Lead.
3. Tech Lead 的技术——概述了不同的技术职责，这些职责将 Tech Lead 与简单的技术经理区分开来。
4. The Tech of a Tech Lead – Outlines different technical responsibilities, which distinguish the Tech Lead from simply being a technical manager.
5. Bridging Business with Tech——强调不同的视角和更外向的关注点。
6. Bridging Business with Tech – Highlights a different perspective and more outward-looking focus.
7. 您– 包含与您作为技术主管的个人相关的回复。
8. You – Contains responses that relate to you, as an individual, in the role of a Tech Lead.

我试图将响应分解为这些不同的主题，并添加一些我自己的经验和对响应中出现的内容的观察。我希望这些主题能让你理解和驾驭 Tech Lead 角色的各个方面，希望它们能让你在未来更容易回顾。

I have attempted to break down the responses into these different themes, adding in some of my own experiences and observations about what emerged in the responses. I hope the themes enable you to get understand and navigate the various dimensions of the Tech Lead role and hopefully they will make it easier for you to refer back to in the future.

下一页显示了书中的回复词云。词云包含频繁出现的关键词，并突出了访谈中出现的更多主题。你可能会注意到一些大字体的词与出现的整体主题相对应，包括频繁使用“人”这个词以及思考“代码”。

The next page shows a word cloud based on the responses in this book. The word cloud contains keywords that recur frequently and highlights further themes that emerged from the interviews. You may notice that some of the words in large type correspond with the overall themes that emerged, including frequent use of the word “people” as well as thinking about “code”.

新手

Novices

“在初学者的头脑中有很多可能性；在专家看来，几乎没有。” – Shunryu Suzuki Zen Mind, Beginner's Mind

“In the beginner’s mind there are many possibilities; in the expert’s mind there are few.” – Shunryu Suzuki Zen Mind, Beginner’s Mind

本节中的故事展示了开发人员在担任 Tech Lead 角色时发现的最显着差异。他们的观点很重要，因为他们强调了开发人员面临的挑战以及他们必须如何适应和找到新角色所需的技能。

The stories in this section demonstrate the most significant differences that developers discover when they move into the role of Tech Lead. Their views are important because they highlight the challenges that developers face and how they must adapt and find the skills required for their new role.

通过更好地了解关键对比领域，组织和管理层可以通过有针对性的培训和辅导为过渡到这些角色的人们提供更多支持。

With a better understanding of the key contrast areas, organisations and management can provide more support to people transitioning to these roles through targeted training and coaching.

更广阔的视野

A Wider Outlook

开发人员一直在处理小细节。他们必须确保不要忘记那个分号，那个额外的逗号，或者其他一些特殊的符号，这些符号会在工作和失败之间产生区别。正确实施功能意味着关注当下的细节。优秀的开发人员会考虑设计他们的功能以及它如何适应更广泛的环境；Tech Leads 花费大量时间思考更广泛的背景。

Developers deal with the small details all the time. They must be sure not to forget that semi-colon, that extra comma, or some other special symbol that will make the difference between something working and failing. Implementing features correctly means focusing on detail in the present. Good developers think about designing their feature and how it fits into the broader context; Tech Leads spend much of their time thinking about the broader context.

技术负责人会花更多时间思考系统的未来状态，以及今天添加功能对明天添加功能的影响。“足够好”的设计和实现并不是原始开发人员是唯一能够理解和维护它的人。考虑整个开发团队是否能够理解和塑造它是 Tech Lead 的工作。

A Tech Lead spends much more time thinking about the future state of the system, and the impact that adding a feature today will have on adding features tomorrow. A ‘good enough’ design and implementation is not one where the original developer is the only person able to understand and maintain it. It is the job of the Tech Lead to consider whether or not the entire development group will be able to understand and shape it.

正如本章中的人们所观察到的，技术主管必须花更多时间看大局；考虑今天的决定对未来的影响。例如，选择一种新的编程语言来解决问题对于团队中的一个开发人员来说可能是最简单和最合适的，但是技术主管意识到它可能在部署环境中引发的潜在挑战，例如所有机器上都可用的新编程语言；确保整个团队能够理解和维护相同的代码库；可能必须花在发展新技能上的时间。

As people in this chapter observe, the Tech Lead has to spend more time seeing the bigger picture; thinking about the future consequences of today’s decisions. The choice of a new programming language to tackle a problem might be the easiest and most appropriate to one developer on the team, for example, but the Tech Lead is aware of the potential challenges it could throw up in the deployment environment, such as having the new programming language available on all machines; making sure the entire team can understand and maintain the same codebase; the time that may have to be spent on developing new skills.

选择不再根据“这对我有用”来评估，而是根据更广泛的生态系统来评估。技术负责人根据决策对其他方的影响来评估决策。他们花更多时间考虑以下问题：

Choices are no longer evaluated in terms of ‘this works for me’, but the broader ecosystem. The Tech Lead evaluates a decision in terms of the consequences it will have for other parties. They spend more time considering questions such as:

• 这种选择是否限制了我们可以为业务或产品经理做的事情？
• Does this choice limit what we can do for the business or product manager?
• 团队的其他成员能否理解并更改或扩展设计？
• Can other members of the team understand and change or extend the design?
• 做出这种选择是否会威胁最终用户的性能或用户体验？
• Will making this choice threaten the performance or user-experience for end-users?
• 这种选择是否只是将工作转移给我们组织中的其他方，这对业务有利吗？
• Does this choice simply shift work to other parties in our organisation and is that beneficial for the business?
• 从长远来看，这种设计会创造更多的工作吗？
• Will this design create more work in the long run?

感受到更大的责任

Sensing Greater Responsibility

“能力越大，责任越大” ——《蜘蛛侠》中的 本叔叔

“With great power comes great responsibility” - Uncle Ben from Spiderman

组织通常将 Tech Leads 指定为授权点。组织的其他部分相信 Tech Lead 会带领他们的团队取得成功，这会带来对组织其他部分的责任。

Organisations often designate Tech Leads as a point of authority. Other parts of the organisation trust the Tech Lead to lead their team to success and this brings with it accountability to the rest of the organisation.

例如，产品经理可能会要求 Tech Lead 与团队的其他成员一起寻找问题的解决方案，但最终将由 Tech Lead 来解释为什么这是最好的解决方案或什么选择的后果可能是。

A Product Manager may ask the Tech Lead to work with the rest of the team to find the solution to a problem, for example, but ultimately, it is the Tech Lead who will be called upon to explain why it is the best solution or what the consequences of a choice might be.

当他们转任 Tech Lead 的角色时，开发人员会发现自己与业务的其他部分更接近了。他们越来越意识到决策的时间敏感性，因为时机可能直接影响企业的盈利能力，而这些必须保持一致。

When they move into the role of Tech Lead, developers find themselves closer to the rest of the business. They become more aware of the time-sensitive aspect of making decisions, because the timing may directly affect the ability of the business to make money and these have to align.

指导技术愿景

Guiding the Technical Vision

Tech Lead 试图拉近团队成员之间的距离，以便他们以相同的眼光看待事物。Tech Lead 欣赏每个人处理问题的方式不同。他们投入时间帮助团队理解技术愿景，以便整个团队朝着同一个方向齐心协力。技术负责人意识到他们最终要负责指导团队。

The Tech Lead attempts to bring team members closer together, so they see things in the same light. The Tech Lead appreciates how everyone approaches problems differently. They invest time in helping the team understand the Technical Vision so the entire team is pulling together in the same direction. The Tech Lead realises they are ultimately responsible for steering the group.

随着时间的推移，技术负责人开始认识到人们对同一消息的理解有多么不同，并且必须找到其他方式来传达相同的想法以避免误解。有些人可能会在谈论之后理解一个想法；有些人需要时间来吸收想法并做出反应，而另一些人则认为白板上的图表更容易阅读，因为他们依赖于可视化。

Over time, the Tech Lead starts to recognise how differently people can interpret the same message and has to find alternative ways of communicating the same idea to avoid misunderstandings. Some people may understand an idea after talking about it; some need time to absorb the idea and respond, and yet others find a diagram on a white board easier to read because they depend on visualisation.

正如一位受访者简洁地说：

As one interviewee succinctly said:

“沟通需要时间。”

“Communication takes time.”

编写代码的时间更少

Less Time for Writing Code

正如我在本书简介中所定义的，我希望技术主管至少将 30% 的时间花在编码上。我不希望他们一直在编写代码，因为他们有更多的责任。技术负责人在编写代码上花费的时间更少，因为需要付出努力从细节缩小到更大的图景，并考虑今天的决定对未来的影响。

As I defined in the introduction to this book, I would expect Tech Leads to spend at least 30 per cent of their time coding. I wouldn’t expect them to be writing code all the time because they have considerably more responsibilities. The Tech Lead spends less time writing code because of the effort required to zoom out from the fine detail to the bigger picture and to think about the impact that today’s decision has on the future.

没有花在编码上的时间可能会用来帮助其他开发人员解决问题，可能因为需要不同的技能组合或方法而将他们与团队中的其他开发人员联系起来，或者帮助他们与团队外的人联系起来。Tech Leads 通常（但不总是！）比一些开发人员有更多的经验，所以自然地，他们的一些时间会花在教学上。Tech Lead 不仅会花时间查看代码味道，还会观察阻碍团队的团队互动和环境限制。

Time not spent coding may be spent helping other developers on problem-solving, perhaps connecting them with other developers in the team because a different skill set or approach is needed, or helping connect them with people outside of the team. Tech Leads often (but not always!) have more experience than some of the developers and so naturally, some of their time will be spent teaching. The Tech Lead also spends time looking not just at code smells, but also observing team interactions and environmental constraints that hinder the team.

Tech Leads 花在编写代码上的时间更少，因为他们被期望与组织中的其他角色互动。与组织中的其他人建立关系需要时间，这通常意味着 Tech Lead 需要比团队其他成员参加更多的会议。

Tech Leads have less time to spend on writing code because they are expected to interact with other roles in the organisation. Building relationships with other people in the organisation takes time and it usually means the Tech Lead needs to attend many more meetings than the rest of the team.

我采访过的许多新手在过渡到 Tech Lead 角色时都遇到了困难，因为他们写代码的时间更少。作为开发人员，您会根据通过编写的代码启用的功能来感知您增加的价值。当您担任 Tech Lead 角色时，这种价值会受到威胁，因为其他任务会让您远离编写代码。

Many novices I interviewed struggled with the transition into the Tech Lead role because they had less time to write code. As a developer, you perceive the value you add in terms of the functionality you enable through the code that you write. When you take on the Tech Lead role, this value is threatened because other tasks draw you away from writing code.

我也为此苦苦挣扎，直到我意识到 Tech Lead 带来价值的方式是完全不同的。Tech Lead 通过让团队中的每个人尽可能多地贡献代码来带来价值；通过避免由于人们以不同的方式工作而导致的重写；通过管理技术债务使添加代码变得更容易，并通过促进开发团队和业务同事之间的关系来确保代码实现业务目标并提供真正的价值。作为领导者，您使他人能够完成他们的工作；你协调并因此最大化整个团队的努力，而不仅仅是个人。

I too struggled with this until I realised that the way the Tech Lead brings value is completely different. The Tech Lead brings value by enabling everyone on the team to contribute code as much as possible; by avoiding rewrites due to people working in different ways; by managing technical debt to make it easier to add code, and by promoting relationships between the development group and business colleagues to ensure the code addresses business goals and delivers true value. As a leader, you enable others to do their work; you harmonise and thereby maximise the efforts of the entire group, not just an individual.

处理更多上下文切换

Juggling More Context Switches

本节中的人员讨论了除了构建技术解决方案之外还要承担新的责任。他们发现自己参加了更多的会议，需要提升到抽象层次，或者帮助人们解决系统中完全不同部分的不同问题。

The people in this section talk about picking up new responsibilities in addition to building a technical solution. They found themselves in more meetings, needing to rise to abstract levels, or helping people solve different problems in a completely different part of the system.

Tech Lead 的角色通常需要更多的上下文切换，这在您第一次担任该角色时肯定会令人沮丧。学习更好的时间管理和任务管理技巧以及授权技巧将帮助您应对。

The role of a Tech Lead often requires more context switching, which can certainly be frustrating when you first step into the role. Learning better time-management and task-management techniques as well as delegation skills will help you to cope.

允许人们失败

Allowing People to Fail

“学习是软件开发的瓶颈” Anonymous

“Learning is the bottleneck in software development” Anonymous

当您担任 Tech Lead 角色时，您将作为开发人员在该行业工作了一段时间。你会犯一些错误，从中吸取教训，并希望能够保护自己免受应避免的做法的影响。当其他人即将犯错时，你会想跳进去，因为你想帮助避免他们。您可以说服他们使用不同的解决方案，但不幸的是，下次出现类似问题时，他们可能不记得采取该行动方案。

By the time you move into the Tech Lead role you will have spent some time in the industry working as a developer. You will have made some mistakes, learned from them and, hopefully, be able to guard yourself against practices to avoid. When other people are about to make mistakes, you will want to jump in because you want to help avoid them. You may convince them to use a different solution, but unfortunately, the next time a similar problem arises, they may not remember to take that course of action.

给 Tech Lead 的一个惨痛教训是允许人们失败，允许他们犯错误。失败是学习过程的自然组成部分；它迫使您评估情况并重试。引导人们找到解决方案可以完全避免失败。如果您阐明备选方案和解决方案背后的思维过程，有些人能够学习，但根据我的经验，没有多少人可以通过这种方式学习。

A hard lesson for the Tech Lead is allowing people to fail, allowing them to make mistakes. Failure is a natural part of the learning process; it forces you to evaluate circumstances and try again. Directing people to a solution avoids failure altogether. Some people are able to learn if you articulate the alternatives and the thought process behind the solution, but in my experience, not many people can learn this way.

通过减少反馈时间来创造安全。也许在一项新任务开始时，您每天与一个人核对一下，看看他们是如何解决问题的，并提出问题让他们看到他们的解决方案中的权衡。允许他们尝试自己的方法，但如果您感觉方向不对，请想办法让他们自己看看。

Create safety by reducing the time for feedback. Perhaps at the start of a new task, you check in with a person daily to see how they are approaching the problem and to ask questions to get them to see trade-offs in their solution. Allow them to try their own approaches, but if you sense it is heading in the wrong direction, find ways to let them see that for themselves.

提出正确的问题，决定何时签到——不要太频繁也不要太久——这些技能需要时间来培养。

Asking the right questions, deciding when to check-in – not too often and not for too long – are skills that take time to develop.

人的方面很难

People Aspects are Hard

我在本节中采访的人写了关于人员管理令人惊讶的困难的一面。作为一名开发人员，您将与您一起工作的人视为同事，视为个人。当您成为 Tech Lead 时，协调团队需要您花时间了解个人并专注于改善个人之间的互动。

People I interviewed in this section wrote about the surprisingly difficult side to people management. As a developer, you see the people you work with as colleagues, as individuals. When you become a Tech Lead, harmonising the team requires you to spend time understanding individuals and focus on improving interactions between the individuals.

与计算机打交道与与人打交道完全不同。计算机不会顶嘴，也不会（通常）喜怒无常。您可以立即使用计算机工作，而与人建立信任需要时间。计算机会继续工作，直到出现故障，而人们在工作之外的生活可能会影响他们的情绪和他们的工作表现。

Working with a computer is a complete contrast to working with people. Computers do not talk back and are not (usually) temperamental. You can work with a computer instantly, whereas it takes time to build trust with people. Computers continue to do their work until they break, while people have lives outside of work that may affect their moods and how well they do their job.

你也是人，作为 Tech Lead，你必须意识到自己的心情和情绪。团队会观察、观察和判断你说的每一句话和做的每一个动作，不管你喜不喜欢或想要。您需要仔细考虑您的言行选择，因为人们会很快误读和曲解您的意图。

You are a person too, and as a Tech Lead you must be aware of your own mood and emotions. The team will watch, observe, and judge every word you utter and every action you make, whether or not you like it or want it. You need to consider your choice of words and actions carefully as people can quickly misread and misinterpret what you intend.

不同的视角——Cameron Swords

A Different Perspective – Cameron Swords

描述 Tech Lead 的职责

Describe what responsibilities the Tech Lead has

从技术角度来看，我的角色包括：

From a technical perspective, my role included:

• 设定与业务愿景一​​致的技术愿景（尽管这已经基本完成）
• Setting out a technical vision that aligned with the business vision (although this was pretty much done)
• 帮助向利益相关者传达技术问题、问题和解决方案
• Helping communicate technical issues, problems, and solutions to stakeholders
• 管理发布 - 确定我们要发布的内容、发布时间以及可能发布的内容
• Managing releases - determining what we’re releasing, when, and what’s possible

从领导的角度来看，我的角色包括：

From a leadership perspective, my role included:

• 确保每个人都朝着同一个方向前进；朝着同一个愿景
• Ensuring everyone moved in the same direction; towards the same vision
• 了解每个开发人员的目标、兴趣和优势
• Understanding each developer’s goals, interests, and strengths
• 通过以适合他们技能的方式挑战他们来支持他们
• Supporting people by challenging them in a way appropriate to their skills

Tech Lead 的角色有什么惊喜吗？

Does the role of Tech Lead hold any surprises?

Tech Lead 的角色让我有机会从“局外人”的角度来看待团队。作为“局内人”在团队中工作和与团队一起工作，我经常会对人和所做的决定持批评态度；它影响了我对我们团队成功的看法。

The Tech Lead role gave me the opportunity to view the team from the perspective of an “outsider”. Working on and with teams as an “insider”, I would often be quite critical of people and the decisions made; it affected how I felt about our success as a team.

拥有外部视角意味着我可以理解其他人如何衡量团队的成功。这与我自己的非常不同。

Having an outside perspective meant I could understand how other people measure the team’s success. It was very different from my own.

优点和缺点

The pros and cons

我对技术愿景和团队运作方式的影响肯定更大。拿着“权威棒”，意味着别人对你使用“权威棒”的可能性更小。这给了我更多的机会来赋予战壕中的人们权力。

I definitely had more influence on both the technical vision and the way the team was run. Holding the “authority stick” means there is less chance of someone else using the “authority stick” on you. That gave me more opportunity to empower people in the trenches.

我花更少的时间编码。我想如果我和一个更高级的团队一起工作，我会编写更多的代码。我还发现管理人员并不是让我快乐的原因。构建能够帮助人们的解决方案让我感到高兴。因此，您只是“必须”完成 Tech Lead 角色的某些部分。

I spent less time coding. I’d like to think I would code more if I worked with a more senior team. I also found that managing people is not what makes me happy. Building solutions that enable people is what makes me happy. So there are parts of the Tech Lead role that you just “have” to do.

有什么准备建议吗？

Any preparation advice?

我觉得我花了很多时间“准备”。在某些时候，我认为你只需要跳进去扮演 Tech Lead 的角色。

I feel like I spent a lot of time “preparing”. At some point, I think you just need to jump in and play the role of Tech Lead.

我确实注意到一些开发人员（一些非常初级）说他们想成为一名技术主管。我想找到一种方法让他们更好地了解角色是什么，这样他们就可以对自己的职业做出更明智的判断。

I do notice some developers (some very junior) say they would like to be a Tech Lead. I would like to find a way to give them a better understanding of what the role is, so they can make a more informed judgment about their career.

你去哪里寻求支持？

Where do you go for support?

前技术负责人（本书的编辑）参与了我的项目并指导了我。我的团队非常支持我，尤其是在我刚开始的时候。我还发现Tech Lead 午餐很有用。

The former Tech Lead (this book’s editor) was on my project and mentored me. My team was very supportive of me, particularly when I first started. I also found the Tech Lead lunches useful.

什么是 Tech Lead 午餐？ What is a Tech Lead lunch? 我们举办了午餐会，邀请现有的技术主管或有兴趣成为技术主管的人。在这种非正式的环境中，我们讨论了具有挑战性的情况，互相询问了作为 Tech Lead 所关心的问题，并为彼此提供了解决问题的不同方法。 We held lunches inviting either existing Tech Leads or people interesting in being a Tech Lead. In this informal setting, we discussed challenging situations, asked each other questions about concerns as a Tech Lead and offered each other different ways to approach problems.

你的观点改变了吗？

Has your perspective changed?

作为一名开发人员，我现在更加昂首挺胸，努力支持团队中的领导者。

As a developer, I keep my head up a lot more now to try and support the leaders in the team.

Cameron 的关键问题：我不知道问题是什么！这是我想回答的。

Cameron’s key question: I’ve no idea what the question is! Here is what I want to answer.

从团队中抽调一位最有经验的程序员担任 Tech Lead 是一种错误的模式。我热衷于修复它。如果有更多的时间和机会担任这个角色，这就是我将要尝试做的事情。

Taking one of the most experienced programmers out of the team to be the Tech Lead is a broken model. I am passionate about fixing it. Given more time and opportunity in the role, this is what I’ll be trying to do.

卡梅伦的背景故事

Cameron’s background story

Cameron 在悉尼大学学习计算机科学，七年前作为毕业生加入 ThoughtWorks。最近，他花了两个月的时间在一个由大约 12 名开发人员组成的团队中担任技术主管。

Cameron studied Computer Science at the University of Sydney and joined ThoughtWorks as a graduate seven years ago. He most recently spent two months playing the Tech Lead role with a team of about 12 developers.

焦点的改变——安妮·西蒙斯

Change of Focus – Anne Simmons

Tech Lead 的角色有什么惊喜吗？

Does the role of Tech Lead hold any surprises?

到目前为止，对我来说最大的不同是焦点的改变，因为你需要更多地关注整体愿景。您仍然必须专注于小任务，例如开发功能和维护质量。同时，您必须快速从该项目的微观视图切换到更宏观的项目视图。

The biggest difference for me so far is the change in focus, as you need to focus more on the overall vision. You still have to focus on small tasks such as developing features and maintaining quality. At the same time, you have to quickly switch from that micro view to a more macro view of the project.

您需要考虑一个功能对整个系统架构的影响，花更多的时间来指导功能的方向并为即将开展的工作提供输入。我发现当人们来找你寻求帮助或问题时，你需要相当频繁地切换上下文，而且通常很快。

You need to consider a feature’s impact on the overall system architecture, spend more time guiding the direction of features and giving input into upcoming work. I have found that you need to switch contexts fairly frequently, and often swiftly, as people come to you for help or questions.

优点和缺点

The pros and cons

我享受责任感。我喜欢能够帮助人们解决问题，并弄清楚如何让每个人发挥最大的作用。我也喜欢参与未来工作的规划过程以及与其他角色的更多互动。

I enjoy the sense of responsibility. I enjoy being in a position to help people untangle problems, and figuring out how to get the best out of everyone. I also enjoy being part of the planning process for future work and the increased engagement with other roles.

我发现很难知道什么该担心，什么不该担心。我仍然发现很难确定短期内应该关注哪些“气味”，哪些可以推迟担心。我认为其中很多都是经验带来的。我开始意识到你不能同时解决或担心所有事情，对我来说，放手让事情自行解决是一个挑战，而他们经常这样做。我发现很容易对角色的所有不同方面感到不知所措。

What I found hard was knowing what to worry about, and what not to. I still find it difficult to work out which ‘smells’ to focus on in the short term, and which ones are okay to defer worrying about. I think a lot of this comes with experience. I have come to realise that you can’t tackle or worry about everything at once and it is a challenge for me to let go enough for things to sort themselves out, which they often do. I find it is easy to get overwhelmed with all the different aspects of the role.

有什么准备建议吗？

Any preparation advice?

在我之前的团队中，我们引入了 Feature Lead 的角色。功能负责人负责指导和完成整个功能。他们参与分析、领域建模和架构，以及部分开发。我认为这是一种很好的方式，可以在不实际成为Tech Lead的情况下接触到一些 Tech Lead 的职责。

On my previous team, we introduced the role of Feature Lead. A Feature Lead takes responsibility for the direction and completion of a whole feature. They take part in the analysis, domain modelling and architecture, as well as part of the development. I think this is a great way to get exposure to some of the Tech Lead responsibilities without actually being the Tech Lead.

你去哪里寻求支持？

Where do you go for support?

我努力充分利用我团队中优秀的技术主管。我要求参加他们开展的一些活动，并要求他们解释背后的思考过程，为什么以及如何确定优先次序并做出决定。

I try to get the most out of the great Tech Leads on my team. I ask to attend some of the activities they run, and ask them to explain the thought processes behind why and how they prioritise and make decisions.

如果有某种神奇的培训课程或书籍告诉您如何成为一名出色的 Tech Lead，那就太好了；此刻，你似乎只是被扔进了这个角色，并且必须一路弄清楚。

It would be great if there were some kind of magical training course or book that told you how to be a great Tech Lead; at the moment, you seem to just get thrown into the role and have to figure it out along the way.

你的观点改变了吗？

Has your perspective changed?

在扮演过一次 Tech Lead 角色之后，作为一名开发人员，我试图确保我了解我正在处理的元素如何适应应用程序的大局。我更多地考虑它如何为更广泛的战略和目标做出贡献。

After playing the role of Tech Lead role once, I try to make sure that, as a developer, I understand how the element I am working on fits into the bigger picture of the application. I think more about how it contributes to the wider strategy and purpose.

我也尝试更多地参与到相邻的团队和故事的计划中，这样它就不会完全取决于 Tech Lead。

I also try more to get involved with adjacent teams and planning of stories so that it is not all up to the Tech Lead.

Anne 的关键问题：您认为 Tech Lead 的角色需要什么？

Anne’s key question: What do you feel that the role of a Tech Lead entails?

我认为每个人对 Tech Lead 的期望都不一样。有些人想要命令和控制的风格。他们想要一个技术人员来告诉他们如何做每件事。其他人则希望有人领导团队并帮助他们成为一个更好的工作单位。所有类型的人都可以成为优秀的 Tech Lead，只要他们周围都是优势互补的人。但是，如果你是一种类型的领导，而人们期待或想要另一种类型的 Tech Lead，那么履行这个角色可能会很困难。

I think everyone has different expectations of a Tech Lead. Some people want a command-and-control style. They want a technical person who will tell them how to do everything. Others want someone who will lead the team and help them become a better working unit. All types of people can make great Tech Leads, as long as they are surrounded by people with complementary strengths. But, if you are one type of lead and people are expecting, or wanting, another type of Tech Lead, fulfilling the role can be hard.

安妮的背景故事

Anne’s background story

Anne 毕业于女王大学（贝尔法斯特），毕业后加入 ThoughtWorks，在加拿大、美国和英国工作。她目前是一名高级开发人员，在一个混合学科开发团队工作。最近，她开始在开发团队中担任更多的领导角色，领导功能区域的设计或在技术主管不在时填补他们的空缺。

Anne graduated from Queen’s University (Belfast) and joined ThoughtWorks as a graduate, working in Canada, all over the US and in the UK. She is currently a senior developer, working as part of a mixed-discipline development team. She has, more recently, started to take more of a lead role in the development team, leading the design in feature areas or filling in for the Tech Lead when they are away.

她觉得这个角色是一种自然的进步，因为她喜欢指导、指导他人以及在团队内部和团队之间建立联系。

She feels like the role is a natural progression as she enjoys mentoring, coaching others and building bonds within and between teams.

在加入 IT 之前，她兼职担任滑雪教练！

Before joining IT, she moonlighted as a ski instructor!

需要更广泛的技能——Ebony Pierce

Needs for a Wider Skill Set – Ebony Pierce

Tech Lead 的角色有什么惊喜吗？

Does the role of Tech Lead hold any surprises?

我作为开发人员的角色和我作为 Tech Lead 的角色之间的主要区别在于项目的重点。作为一名开发人员，我对自己的角色和指定的项目截止日期负责。我的关注始终以团队为导向，确保参与项目的每个人都能在项目截止日期前完成，但我的重点主要放在我正在从事的项目上。

The primary difference between my role as developer and my role as Tech Lead is the focus of projects. As a developer, I was responsible for my role and my designated project deadlines. My concern was always team oriented, making sure that everyone working on the project was able to meet the project deadline, but my focus was primarily on projects that I was working on.

作为 Tech Lead，我不仅要以目标为导向，还要以人为本。过去我只负责自己的工作，突然间我开始负责多个开发人员和多个项目的工作：确保不拖延最后期限；激励开发人员向前推进，但检查他们没有被拉得太紧；确保道德不下滑；注意我的语气并考虑传达信息的方式；确保开发人员有资源来完成他们的项目，并且资源得到适当的管理。

As a Tech Lead, I have to be not only goal-oriented, but also people-oriented. Where I used to be responsible for only my work, I suddenly became responsible for the work of several developers and multiple projects: ensuring that deadlines are not slipping; motivating developers to press forward but checking they are not stretched too thinly; ensuring that moral is not slipping; watching my tone and considering the way information is communicated; ensuring developers have the resources to get their projects completed, and that resources are managed appropriately.

我面临的一些挑战包括： 从管理自己的工作到管理他人的工作；从与开发人员一起工作多年到管理他们；监控我如何与个人交谈以尽量减少误解；在专业和个人之间划清界限，并且必须重新构建对话和情况以免冒犯任何人。在我看来，最困难的部分是从与人一起工作到管理他们的转变。有时很难将两者区分开来，因为作为一个团队合作者，如果你知道同事的不足，你会替他们做掩护，但作为领导，你有责任把事情做好，你真的必须改变你的方式看东西。

A few of the challenges that I have include: going from managing my own work to the work of others; going from working alongside developers for years to managing them; monitoring how I speak to individuals to minimise misunderstandings; drawing a distinct line between professional and personal, and having to reframe conversations and situations so as not to offend anyone. The hardest part, in my mind, is the shift from working alongside people to managing them. It is sometimes difficult to separate the two, because as a team player, you cover for a co-worker if you know they are lacking, but as a lead, you are responsible for getting things done and you really have to change the way you look at things.

优点和缺点

The pros and cons

我喜欢 Tech Lead 角色的一个原因是我有机会看到全局。我看到日常工作如何与合同和公司相互作用，以及我的贡献和开发人员的贡献如何直接影响整个公司的成功。

One of the things that I like about the Tech Lead role is that I have the opportunity to see the whole picture. I see how the day-to-day work interacts with the contract and company, and how my contributions and the contributions of the developers directly affect the success of the entire company.

老实说，我最不喜欢这个角色的是与人打交道。很长一段时间以来，我一直在与计算机打交道：你准确地告诉它们你想要什么，它们就会完成一项任务。很难过渡到管理人员的角色，因为人不像计算机那样工作。如果你告诉一个人一些他们不接受的事情，可能会导致以下几种情况：他们可能会按照要求去做；他们可能会说他们会按照要求去做，然后表现不佳或采取消极进取的方式；他们可能根本不按要求去做。很难根据每个人的个性和气质来调整你的方法，而对于计算机来说，语言总是一样的；他们不会读懂语气或肢体语言：只要你的指示是具体的，任务就完成了。

Honestly, the thing I dislike most about the role is dealing with people. For a long time, I have worked with computers: you tell them exactly what you want and they complete a task. It is difficult to transition into a role where you manage people, because people do not work like computers. If you tell a person something they are not receptive to, several things could result: they may do what is requested; they may say they’ll do what is requested, then underperform or take a passive-aggressive approach; they may simply not do what is requested. It is difficult to adapt your approach for each individual based on personality and temperament, whereas for a computer, the language is always the same; they do not read into tone or body language: as long as your directions are specific, the task is completed.

有什么准备建议吗？

Any preparation advice?

我认为为这个角色做准备的最好的事情是获得心理学学位，重点是肢体语言阅读和非语言交流，以及一张严肃的扑克脸。因为我没有，所以我认为多样化的体验很重要。Tech Lead 的最佳特征包括适应性、敏捷性、能力、性格、可靠性、可信赖性，当然还有厚脸皮。这些都不是可以教授的技术技能；他们只能通过实践和接触不同的经历和情况来发展。Tech Leads 必须将自己推向挑战和困难的境地，在他们的舒适区之外接受延伸任务，并练习领导会议和演示。技术主管必须学会将情绪排除在外并保持客观性。

I think that the best thing to prepare for this role would have been a degree in psychology, with a focus on body language reading and non-verbal communication, and a solid poker face. As I don’t have that, I think a varied experience is important. The best characteristics of a Tech Lead include adaptability, agility, competence, character, reliability, trustworthiness, and definitely a thick skin. None of these are technical skills that can be taught; they can only be developed with practice and from exposure to different experiences and situations. Tech Leads have to push themselves into challenges and difficult situations, take stretch assignments outside their comfort zone, and practise leading meetings and presentations. Tech Leads have to learn to keep emotions out of the equation and maintain objectivity.

你去哪里寻求支持？

Where do you go for support?

我得到不同导师的支持，其中大多数是男性。我将它们用作想法的共鸣板，以提供有关我的方法和途径的男性视角，并帮助我了解男性同事可能如何看待我的行为。我也得到家人和朋友的支持：专注和目标。我有几位女性导师可以寻求建议和灵感。我正在学习找到适当的工作与生活平衡点，为了保持这种平衡，我定期休假，专注于自己。这些为我提供了更新和“储存”自我支持以备日后使用的机会。

I draw support from different mentors, most of whom are men. I use them as soundboards for ideas, to provide a male perspective of my methods and approach and to help me to understand how male co-workers might perceive my actions. I also draw support from my family and friends: focus and objective. I have several female mentors to turn to for advice and inspiration. I am learning to find an appropriate work-life balance, and to maintain this I take regular vacations where I focus on me. These provide opportunity for me to renew and “store up” self-support for a later date.

你的观点改变了吗？

Has your perspective changed?

作为一名开发人员，我一直试图全面了解我正在处理的系统，并且我一直试图在截止日期方面做到及时。我不会做任何不同的事情。对于其他考虑在某个时候过渡到 Tech Lead 的开发人员，我的建议是问问为什么。找到问题的根本原因大约需要五个为什么；确定需要改进的地方，并更好地了解需要做什么。

As a developer, I’ve always tried to have a complete understanding of the system that I was working on and I’ve tried to be prompt as far as deadlines are concerned. I would not have done anything differently. For other developers considering the transition to Tech Lead at some point, my suggestion would be to ask why. It takes about five whys to get to the root cause of an issue; to identify what needs to be improved and to gain a better understanding of what needs to be done.

希望扩展的开发人员需要：

Developers who are looking to branch out need to:

• 保持好奇心
• Be curious
• 彻底
• Be thorough
• 阅读所有内容
• Read everything
• 保持客观性
• Maintain objectivity
• 了解大局。
• Understand the big picture.

Ebony 的关键问题：你如何保持继续从事如此艰巨工作的动力？

Ebony’s key question: How do you maintain the drive to continue with such an arduous job?

我的动力来自于我的贡献很重要以及其他人直接受到我的贡献影响的安全知识。听起来很蹩脚，但这是真的。

I maintain the drive from the secure knowledge that my contribution matters and that other people are directly affected by my contribution. It sounds lame, but it’s true.

乌木的背景故事

Ebony’s background story

Ebony 最初从事 IT 工作，是一名软件开发人员，使用经典的 ASP、JavaScript、CSS 和 HTML 构建网站。在接受采访时，她正在一个九人团队中工作，并在与她的团队合作多年后升任 Tech Lead。尽管她没有 .Net 技术背景，但她通过三个月的专注自学和研究赢得了团队的支持。

Ebony started in IT as a Software Developer building a website using classic ASP, JavaScript, CSS and HTML. At the time of this interview, she was working on a team of nine people and graduated into the role of a Tech Lead after working with her team for several years. Although she didn’t have a background in .Net technologies, she won her team over with three months of focused self-study and research.

杂耍表演——Siebert Lubbe

Juggling Act – Siebert Lubbe

我对 Tech Lead 角色的看法

My view of the Tech Lead role

我认为作为 T​​ech Lead，我有责任带领团队进行良好的软件设计和架构。我们作为一个团队一起做出大多数设计决策，但我有责任促进设计会议并确保我们生产的产品具有高质量并符合组织的技术愿景。

I think it’s my responsibility as Tech Lead to lead the team in good software design and architecture. We make most design decisions together as a team, but it is my responsibility to facilitate the design sessions and ensure that what we produce is of high quality and aligned with the organisation’s technical vision.

在优秀的软件工程方面指导团队和团队成员也是我的工作之一。我花时间与个人和整个团队一起讨论代码质量、最佳实践和设计决策。我们的软件基础设施越来越复杂，所以我尽量让新的团队成员能够介绍我们系统的不同方面。

Mentoring the team and team members in good software engineering is also part of what I take on. I spend time with individuals and the team as a whole to discuss code quality, best practices and design decisions. Our software infrastructure is increasingly complex, so I try to be available to new team members to introduce the different aspects of our systems.

我们以持续交付模式运作。我负责我们的构建和部署管道，并确保我们开发过程的这些部分支持我们的交付要求。我们也是敏捷实践的积极采用者，所以我确保我们在开发过程中坚持这种工作方式。

We operate in a continuous delivery model. I take ownership of our build and deployment pipelines and ensure that these parts of our development process support our delivery requirements. We are also keen adopters of agile practices, so I ensure that we stay true to this way of working during the development process.

沟通占据了我一天的大部分时间。我经常与业务分析师和迭代经理保持联系，以确保我们的团队与产品愿景和更广泛的业务方向保持一致。我还花了大量时间与外部利益相关者交流我们的技术方向。我们的开发团队是我们组织中不断在相同基础设施和代码库上工作的众多团队之一；我的职责之一是与这些开发团队及其技术主管保持沟通，以协调开发工作、发布活动和设计决策。

Communicating takes up a big part of my day. I liaise constantly with the business analyst and iteration manager to ensure that our team is aligned with the product vision and broader business direction. I also spend significant time communicating our technical direction with external stakeholders. Our development team is one of many in our organisation that work constantly on the same infrastructure and code bases; it is part of my responsibility to maintain communication with these development teams and their Tech Leads to co-ordinate development efforts, release activities and design decisions.

我本质上仍然是一名程序员。我喜欢写代码，我把它放在首位。我相信亲身实践是了解我们的全部堆栈并使我能够在技术上领导我们的团队的最佳方式。

I am still a programmer at heart. I love writing code and I make it a priority. I believe that staying hands-on is the best way to understand our full stack and enable me to lead our team technically.

Tech Lead 的角色有什么惊喜吗？

Does the role of Tech Lead hold any surprises?

作为一名开发人员，我通常能够一次专注于一项任务；作为 Tech Lead，我经常同时处理几件事。在任何特定的一天，我必须处理的中断次数显着增加。这需要频繁的上下文切换。我有时发现很难衡量自己的效率和进步。学习如何最好地管理我的个人时间是一个持续的旅程。

As a developer, I was usually able to focus on one task at a time; as Tech Lead I often have a few things going on at the same time. The number of interruptions I have to deal with on any particular day has increased significantly. This calls for frequent context switches. I sometimes find it difficult to measure my own efficiency and progress. Learning how best to manage my personal time is an ongoing journey.

优点和缺点

The pros and cons

我真的很喜欢看到各个方面的大局，包括产品、业务和技术，并参与塑造大局。能够影响技术决策以最好地实现业务需求的职位是非常有益的。

I really enjoy seeing the bigger picture across all aspects, including product, business and technology, and being involved in shaping the bigger picture. It is very rewarding to be in a position where I can influence technology decisions to best achieve business requirements.

带领团队朝着共同的技术愿景迈进也让我感到非常满足。促进技术讨论并激励团队实现卓越技术是我非常喜欢的事情。

I also get great satisfaction from leading a team towards a common technical vision. Facilitating technical discussions and motivating the team to technical excellence is something I enjoy a lot.

作为一名本质上的开发人员，我发现很难适应编写更少代码的现实。然而，另一方面，这段经历让我看到了软件开发中的许多新领域和挑战，我觉得这些领域非常令人兴奋。

Being very much a developer at heart, I have found it hard to get used to the reality of writing less code. On the flipside, however, the experience has opened my eyes to a number of new areas and challenges in software development that I find very exciting.

有什么准备建议吗？

Any preparation advice?

我觉得我在我需要技能的大多数领域都有经验：领导团队、了解我们组织的系统基础设施、时间管理、软件架构技能和敏捷方法。然而，更多的经验总是更好，如果我知道以后需要我做什么，我可能会更专注于这些领域。

I feel that I have had experience in most of the areas where I require skills: leading a team, understanding our organisation’s systems infrastructure, time management, software architecture skills, and agile methodologies. However, more experience would always have been better, and I might have focused a bit more on these areas had I known what was going to be required of me later.

我认为从一开始就有一位导师很重要。我现在有支持，但我没有开始。我会建议任何进入 Tech Lead 角色的人从他们尊重和信任的人那里寻求指导。

I think it is important to have a mentor from the beginning. I have support now, but I didn’t to start with. I would recommend anyone moving into the Tech Lead role to seek mentorship from an individual that they respect and trust.

你去哪里寻求支持？

Where do you go for support?

我的直属经理帮助我确定了对我的角色的期望，并设定了目标以弥补我在适应新角色时的技能差距。这是一个很好的支持来源。我发现，当我诚实并清楚地知道我想提高自己的技能的哪些领域时，与我的直线经理的讨论是最有建设性的。

My line manager has been helpful in defining the expectations for my role and setting objectives to address my skill gaps as I was settling into the new role. This has been a great source of support. I have found that discussions with my line manager are most constructive when I am honest and clear about which areas I would like to improve my skill set in.

与直属团队以外的同事讨论我的角色和当前挑战也很有帮助。这可能意味着边喝咖啡边进行简单的临时聊天或预定每两周一次的会议。就我而言，有两个人是我非常尊重的：一个是经验比我多一点的同行；另一个是有着多年经验和丰富知识的前辈。

Discussing my role and current challenges with colleagues outside of my immediate team is also helpful. This could mean a simple ad hoc chat over a coffee or booking a fortnightly meeting. In my case, there have been two individuals that I respect a lot: one a peer with a little more experience than I; the other a senior with quite a few years of experience and a wealth of knowledge.

你的观点改变了吗？

Has your perspective changed?

我现在更加了解大局以及我们所做的工作如何为组织做出贡献。我对什么是对技术和最终业务愿景的宝贵时间和精力投资的看法发生了变化。我一直很看重聪明的工程解决方案，但我越来越意识到，好的软件设计决策会带来更面向未来、易于维护的系统，并且必须与业务需求保持一致。

I am more aware of the bigger picture now and of how what we do contributes to the organisation. My perspective has changed about what is a valuable investment of time and effort towards technical and ultimately business vision. I have always valued clever engineering solutions, but I am increasingly aware that good software design decisions lead to more future-proof, easy-to-maintain systems, and must be well aligned with business requirements.

西伯特的背景故事

Siebert’s background story

Siebert 在南非比勒陀利亚大学学习计算机工程，过去 10 年一直从事 IT 工作。尽管他对软件安全特别感兴趣，但他对所有与软件开发相关的事情都很感兴趣。

Siebert studied Computer Engineering at the University of Pretoria, South Africa and has been working in IT for the last 10 years. He gets excited about all things related to software development although he has a particularly keen interest in software security.

他目前在澳大利亚墨尔本的 realestate.com.au 担任开发团队的技术主管。

He currently holds the Tech Lead role for a development team at realestate.com.au in Melbourne, Australia.

外部面孔——Liz Douglass

The External Face – Liz Douglass

Tech Lead 的角色有什么惊喜吗？

Does the role of Tech Lead hold any surprises?

我角色的面向外部的方面与我以前所做的明显不同。除了密切关注每个开发人员的情况并尝试预测团队中即将发生的事情外，我发现我需要与我们合作的团队保持定期对话。这既包括基础设施、BAU（照常营业）、架构等 IT 部门，也包括销售和市场营销等非 IT 部门。在团队之外建立和维持良好的关系对我们来说非常重要。

The external-facing aspect of my role is noticeably different from what I’ve done before. As well as keeping an eye on what’s happening with each developer and trying to anticipate what’s coming up within the team, I’ve found that I need to keep a regular dialogue going with the teams that we partner with. This includes both IT groups such as infrastructure, BAU (business as usual), architecture, as well as non-IT groups such as Sales and Marketing. Establishing and maintaining good relationships outside the team has been really important for us.

优点和缺点

The pros and cons

总的来说，我真的很喜欢这个角色。我喜欢能够与更多人分享想法，并研究我们如何才能实现最大和最快的目标。我喜欢拿起白板笔并促进关于我们正在做的事情以及我们可能如何取得进展的讨论。

Overall, I really enjoy the role. I like being able to share ideas with more people and work through how we can achieve the biggest and fastest. I enjoy grabbing a whiteboard marker and facilitating discussions about what we’re doing and how we might progress.

也就是说，我认为我还没有掌握委派的能力，而且我经常发现自己有太多事情要做。我真的不喜欢在故事深入脚踝时离开我的那双。我还认为扮演两个角色对团队有负面影响，因为我一直不在身边。

That said, I don’t think I’ve yet mastered the ability to delegate and I often find myself with too much on my plate. I really dislike leaving my pair when we’re ankle-deep in a story. I also think playing two roles has a negative impact on the team because I’m not around all the time.

有什么准备建议吗？

Any preparation advice?

我不确定我是否可以做好更好的准备。你永远不会事先知道你将进入什么领域，而这是我们作为顾问所做的最好的部分之一。在过去的几年里，我一直担心需要“无所不知”才能成为 Tech Lead，这当然是一个谬论。与拥有不同经历和想法的人在一起是能够应对任何事情的关键。

I am not sure that I could have been better prepared. You never know in advance what you’re getting into, and that’s one of the best parts of what we do as consultants. In years gone by I have been concerned about needing to ‘know everything’ in order to be a Tech Lead, which, of course, is a fallacy. Surrounding yourself with people who have different experiences and ideas is the key to being able to cope with anything that comes up.

你去哪里寻求支持？

Where do you go for support?

我觉得我很幸运，身边一直有一个很棒的支持网络。在这个项目中，我们有一个很棒的团队，包括一位专业管理外部利益相关者的项目经理。我们还有一位出色的业务分析师，他真正为客户着想，是一位出色的促进者和谈判者。

I think I’ve been quite fortunate to have always had an amazing support network around me. On this project we have a terrific team, including a project manager who expertly manages the external stakeholders. We also have an excellent business analyst, who is really invested in the client and is a great facilitator and negotiator.

我还得到了高级技术专家 Scott Shaw 的支持，他每月有一天来拜访团队，并为我们提供架构和技术方面的建议。

I also have the support of Scott Shaw, a senior technologist, who comes one day per month to visit the team and gives us advice on architecture and technologies.

你的观点改变了吗？

Has your perspective changed?

我现在可能更适应团队和客户组织的更广泛背景。我现在更提倡离开你的椅子并与他人交谈——这可以节省很多时间，而且总是能为每个人带来更好的结果。

I am probably more attuned now to the broader context of the team and the client organisation. I am now even more of an advocate of getting out of your chair and speaking to others - it can save a lot of time and it always leads to better outcomes for everyone.

丽兹的背景故事

Liz’s background story

Liz 以完全不同的背景开始了她的职业生涯，首先从大学毕业，成为皇家墨尔本理工学院的航空航天工程师。她曾在多家不同的航空航天公司工作，这让她首先接触到了软件工程师，并了解了构建脚本、单元测试和其他软件开发实践。

Liz started her career with a radically different background, firstly graduating from University as an aerospace engineer from the Royal Melbourne Institute of Technology. She worked for a couple of different aerospace companies which first brought her into contact with software engineers and she learned about build scripts, unit tests and other software development practices.

她以开发人员的身份加入 ThoughtWorks，曾在多个国家/地区担任过不同的团队和职务。在她目前的角色中（在本次采访时），她同时扮演技术主管和客户负责人的角色，以建立客户在线形象的替代和更新。

She joined ThoughtWorks as a developer and has worked in several countries with different teams and roles. In her current role (at the time of this interview) she plays both the role of Tech Lead and Client Principal in building a replacement and refresh of a client’s online presence.

混乱与无能——罗伊·奥舍罗夫

Chaos and Cluelessness – Roy Osherove

Tech Lead 的角色有什么惊喜吗？

Does the role of Tech Lead hold any surprises?

在我担任第一个 Tech Lead 角色时，最让我惊讶的是我周围的其他人知道的很少：和我一样少。无论我有什么问题，我都从我在其他领导角色中仰望的人那里得到了不完整或糟糕的答案。

On my first Tech Lead role, what surprised me the most was just how little everyone else around me knew: as little as me. Whatever questions I’ve had, I’ve received either incomplete or just horrible answers from people whom I looked up to in other leadership roles.

例如：“我们应该如何处理客户会议？” 和“我们如何制定要求？”。似乎我周围的每个人都和我一样在即兴发挥。

For example: ‘What are we supposed to do with the customer meeting?’ and ‘How do we work out the requirements?’. It seemed that everyone around me was winging it as much as I was.

优点和缺点

The pros and cons

我周围一片混乱和无能为力，这实际上是一件好事。它让像我这样的人，带着一点点决心和一点点胆量，去做我需要、想要并认为对我的团队最有利的事情。人们会问我，'我们到了吗？或者要求我用实际完成任务所需时间的一半完成任务，但最终我是决定项目进度和质量的人。如果您希望有机会在相对无风险的环境中尝试不同的技术，那就太好了。无论如何，那个特定的项目正走向失败，所以我尝试至少通过一些内置的测试驱动开发来做到这一点，尽管这需要时间来学习。

The fact that there was chaos and cluelessness around me was actually a good thing. It allowed someone like me, with a little determination and a little audacity, to do what I needed, wanted, and felt was best for my team. People would ask me, ‘Are we there yet?’ or ask me to finish things in half the time actually needed to accomplish them, but ultimately I was the one dictating the progress and quality of the project. This is great if you want the chance to experiment with different techniques in a relatively risk-free environment. That particular project was heading for failure anyway, so I tried to at least do it with some test-driven development built in, even though that takes time to learn.

有什么准备建议吗？

Any preparation advice?

当被问到不合理的事情时，我会喜欢有人告诉我如何回应。我通常的反应是，“好吧……我们会试试的。” 我不再这样做了，但应该有人告诉我，我的工作是做好我的工作，而不是放弃并接受不可接受的要求。

I would have loved someone to tell me how to respond when asked for unreasonable things. My usual reaction was, ‘Well… we’ll try.’ I don’t do that any more, but someone should have told me it was my job to do my job and not roll over and accept unacceptable requests.

你去哪里寻求支持？

Where do you go for support?

我阅读了神话般的人月和示例测试驱动开发。我读了越来越多的书，发现每个人都有不同的看法，没有人真正知道到底发生了什么。多年后，一位朋友告诉我，“没有专家，只有我们。” 他是对的。

I read The Mythical Man Month and Test Driven Development by Example. I kept reading more and more books and realised everyone has a different opinion, and nobody really knows what’s really going on. Years later, a friend told me, ‘There are no experts, there is only us.’ He was right.

罗伊的背景故事

Roy’s background story

Roy 在以色列出生和长大。他是《The Art of Unit Testing》和《 Notes to a Software Team Leader 》一书的作者，从事技术工作超过 15 年。

Roy was born and raised in Israeli. He is the author of The Art of Unit Testing and Notes to a Software Team Leader and has worked with technology for more than 15 years.

他目前是挪威政府项目团队的高级开发人员/教练/架构师。

He is currently a senior developer/coach/architect in a team working on a government project in Norway.

不仅仅是技术 – Priyank Gupta

More Than Just Tech – Priyank Gupta

我对 Tech Lead 角色的看法

My view of the Tech Lead role

我认为 Tech Lead 负责：

I believe the Tech Lead is responsible for:

• 架构和技术解决方案——我们为一家以减少纸张为使命的小公司工作，我们率先提出了数字文件柜的想法。对内部托管和基础设施的需求不高，创新的需求迫在眉睫。作为其中的一部分，我们在云中提出了一个数字生态系统，以帮助最终客户在各种平台和设备上随时随地安全地访问文档。从一开始，我的角色就​​是协作、指导和建议适合系统的技术架构。它涉及推理和研究，以找到合适的技术来提供开发速度和可扩展性之间的平衡。预计推出第一年的最终用户数量将达到数十万。
• The Architecture and Technical Solution - We worked for a small company that was on a mission to reduce paper and we spearheaded the idea of digital filing cabinets. The appetite for internal hosting and infrastructure was low and the need to innovate was pressing. As part of that we came up with a digital ecosystem in the cloud to help end customers access documents ubiquitously and securely on all sorts of platforms and devices. From the outset, my role was to collaborate, guide, and suggest a suitable technical architecture for the system. It involved reasoning and research to find a suitable technology to provide balance between speed of development and scalability. The anticipated number of end users in the first year of launch was in the hundreds of thousands.

此外，我还专注于 API 设计、Web 平台设计和基础设施以及部署过程。

In addition, I focused on designing the API, the web platform design and infrastructure, and the deployment process.

• 代表离岸业务——因为我在岸上，离客户更近，我的主要职责之一是与离岸团队联络并代表离岸团队。我向岸上的技术人员表达了他们的担忧和问题，并确保每个人都在同一页面上。我将任何重要事件转告给海上特遣队；优先级的任何变化和来回的技术影响。我在这个项目上总共做了大约六个月的时间。
• Representing the offshore presence - As I was onshore, closer to the client, one of my main responsibilities was to liaise with, and on behalf of, the offshore team. I voiced their concerns and issues to the technical folk onshore and ensured that everyone was on same page. I relayed any important occurrences back to the offshore contingent; any changes in priority and the technical impacts back and forth. I did this for a combined period of about six months on the project.
• 跨团队角色协调——我们是开发该产品的核心团队之一，还有其他几个团队与我们一起工作：桌面 API 消费者；移动应用开发商；电子商务平台团队等。我的日常工作需要与他们互动以解决 API 问题，从消费者的角度看待设计问题，以及协调开发 API 和消费者所依赖的功能。这让我有机会分析所有相关的故事，因为需要技术诀窍来详细说明它们。
• Coordinating across team roles - We were one of the core teams working on the product and had several other teams working alongside us: desktop API consumers; mobile app developers; e-commerce platform team, etc. My day-to-day job entailed interacting with them to troubleshoot API issues, looking at design problems from consumer perspectives, and co-ordinating development of API and features that consumers relied on. This gave me the opportunity to analyse all the relevant stories, since tech know-how was required to detail them out.
• 调解决策——在一个固执己见的团队中是一个很好的学习机会，但这可能意味着由于意见分歧，开发人员的讨论会永远持续下去。我担任的角色之一是通过强制决策或权衡业务背景、需求和权衡来整理想法并使每个人达成一致。因此，虽然我们以一种相当理性和民主的方式工作，但我必须表明立场并就一种方法达成一致。
• Mediating decisions - Being in an opinionated team is a great learning opportunity, but it can mean that developer huddles go on for ever, due to divided opinions. One of the roles I assumed was to collate the ideas and bring everyone to an agreement, either by forcing decisions or weighing up business context, needs, and trade-offs. So, while we worked in a fairly rational and democratic way, I was required to take a stand and agree on an approach.
• 开发- 大多数时候，我是团队中的开发人员，这是我最喜欢的部分。我开发了用户故事，但我很少推动它们完成，这依赖于我的搭档。我经常轮换以切换上下文并全面了解我们团队在不同方面所采用的方法。这帮助我在与其他开发人员的不同讨论中将要点联系起来。
• Developing - For most of the time, I was a developer on the team and this was my favourite part. I developed user stories, but I rarely drove them to completion, relying on my pair for that. I rotated frequently to switch context and gain an overall idea of the approach our team was taking on different aspects. This helped me to connect the dots in different discussions with the other developers.

Tech Lead 的角色有什么惊喜吗？

Does the role of Tech Lead hold any surprises?

有几个惊喜对我来说很突出；最大的问题是我必须处理的大多数问题都与技术无关，而与人有关。我必须平衡团队的需求和愿望与业务需求，提出技术建议或推迟某些技术选择。受到业务和开发人员的关注，我的观点从仅关注技术转变为同时考虑业务影响。到项目结束时，业务驱动因素已成为决策的核心考虑因素。

A couple of surprises stand out for me; the biggest was that most of the issues I had to deal with were less about technology and more about people. I had to balance the needs and aspirations of the team with business needs, to make technical recommendations or push back on certain technology choices. Being exposed to concerns from both the business and developers shifted my perspective from being focused solely on technology to considering the business impact as well. By the end of the project, business drivers had become the central consideration in making decisions.

另一个惊喜是需要了解我的团队的积极性。为此，我定期与团队交谈，与个人建立融洽关系，并了解他们的个人优势和抱负。我认为这让我成为了更好的团队合作者，也让我们成为了更好的团队。虽然我一直承认紧密团结的团队的重要性，但这让我亲身体验了积极构建团队的过程。最重要的是，尽管我们是分布式的、共同采购的（ThoughtWorks 和客户的开发人员），而且我们中的大多数人以前从未与其他任何人合作过，但我们组织的建立融洽关系的具体事情确实运作良好。事实证明，这是我在 ThoughtWorks 过去四年中最喜欢的团队。

Another surprise was the need to learn how well motivated my team was. I did this by talking to the team regularly, building rapport with individuals, and finding out about their individual strengths and aspirations. I think this made me a better team player and us a better team. While I have always acknowledged the importance of a closely knit team, this gave me first-hand experience of what goes into proactively building one. The great part was that, although we were distributed, co-sourced (ThoughtWorks and the client’s developers), and most of us had never worked with anyone else before, the specific things we organised to build rapport worked really well. This turned out to be my favourite team of my last four years at ThoughtWorks.

不利的一面是，我讨厌自己无法对某些事情形成意见。作为一名开发人员，如果我没有意见，我有幸不参与讨论。作为 Tech Lead，人们指望我来推动、调解和促进讨论，​​如果我没有意见，这会困难得多。让我感到惊讶的是，突然间，发表意见变得非常重要：捍卫或争论会影响项目架构的关键部分。我在这上面花了很多时间：积累知识以帮助我形成明智的意见；其他学科领域的提问和推理，知识深度不是根本原因。

On the downside, I hated my inability to form an opinion on certain matters. As a developer, I had had the luxury of not taking part in a discussion if I did not have an opinion. As Tech Lead, people looked to me to drive, mediate, and facilitate discussion, and this was much harder if I didn’t have an opinion. It surprised me how, suddenly, it was very important to have an opinion: to defend or argue against crucial bits that would shape the project architecture. I spent considerable time on this: building knowledge to help me form an informed opinion; questioning and reasoning in other subject areas, where depth of knowledge wasn’t the root cause.

优点和缺点

The pros and cons

我喜欢编码。我喜欢沉浸在一段代码中并完成它。但作为 Tech Lead，我必须了解几乎所有代码部分的上下文，这样我才能参与各种讨论而不会迷失方向。这意味着我不得不经常轮换，这让我远离了我本想花时间处理的组件。

I love coding. I love being immersed in a piece of code and taking it to completion. But as Tech Lead I had to get some context on almost all parts of the code so that I could participate in a variety of discussions without getting lost. This meant I had to rotate frequently, which took me away from components I would have loved to spend time working on.

Tech Lead 的另一个主要职责是“解锁”人员。我很想说我在这方面工作，但事实上，我们的团队充满了非常有能力的开发人员，而且我们的想法从来没有用完过。所以，虽然我可以在这方面做得更多，但这并不是真的必要。

Another key responsibility of the Tech Lead is to ‘unblock’ people. I would love to say that I worked on this, but in truth, our team was full of extremely competent developers and we never ran out of ideas. So, while I could have done more in this regard, it wasn’t really necessary.

我真正讨厌的角色的一个方面是进行练习以提供业务方面的进步感。诸如水晶球之类的练习（我们用天数来讨论故事完成的统计表示）；当我们未达到目标速度时，速度合理化。我们很快意识到这些讨论的危险，并试图将重点放在功能完成而不是指标的长期重要性上，但这对业务本身来说很棘手。

One aspect of the role that I really hated was carrying out exercises to provide the business side with a sense of progress. Exercises such as Crystal Ball (a statistical representation where we talked about story completion in terms of days); velocity rationalisation when we were underachieving our target velocity. We soon realised the perils of these discussions and tried to focus on the long-term importance of a feature completion instead of metrics, but it was tricky to the business on side.

另一方面，有些事情我很喜欢：我了解到了解每个人的技术抱负有助于管理团队动态。一个人可能渴望机会，但可能会犹豫是否主动抓住机会。为了能够做好这件事，我定期进行一对一的谈话，以获得反馈和每个人的观点。虽然我不确定我最初的意图有多成功，但它确实让我更好地与整个团队建立了联系。我也对我们的集体能力充满信心，因为我对团队中的个人优势有了更好的认识。

On the other hand, there were things that I loved: I learned that understanding each person’s technical aspirations helps you manage team dynamics. A person may crave opportunities but may hesitate to proactively take them on. To be able to do this well, I had regular one-on-one talks to get feedback and each person’s perspective. While I am not sure how successful I was in my initial intent, it definitely made me connect better to the whole team. I also felt confident of our collective abilities because I had a better sense of individual strengths in the group.

有什么准备建议吗？

Any preparation advice?

对于分布式团队来说，最大的挑战之一是克服与客户和对岸团队面对面交流的时间不足的问题。当团队位于同一地点时，融洽关系和信任度会建立得更快更好。我记得有几个例子，如果团队一开始就在同一地点，我会更成功。我将尝试用我对这段经历的记忆来证实。

For a distributed team, one of the biggest challenges is overcoming the lack of face time with the customer and the team on the other shore. The rapport and level of trust builds quicker and better when a team is co-located. There are a couple of instances that I can recall, where I would have been more successful if the team had been co-located to start with. I’ll try to substantiate with my memory of the experience.

在项目的前两个月，我有机会在他们的办公室与客户一起工作。这太棒了：我能够建立融洽的关系；我得到了陆上团队的信任，并将其带回了海上。我们与每个人轮流在整个团队中传播这种信任，并且效果很好。项目实施几个月后，客户开始了一小部分开发工作，全部由陆上人员组成。我们之前都没有和那个流中的任何人一起工作过。我们共享一个代码库。由于我们仅通过电话进行交互，因此很难推回或详细讨论以确保我们在架构方面达成一致。

I had the opportunity to work with the client in their office for the first two months of the project. This was great: I was able to build rapport; I had the trust of the onshore team, and I took that back to offshore. We rotated with everyone to propagate this trust across the team and it worked well. A few months into the project, the client started a small stream of development, staffed entirely by onshore people. None of us had worked with anyone from that stream before. We shared a single codebase. Since we interacted only over the phone, it was harder to push back or talk at length to ensure we were on the same page regarding the architecture.

因为我们有单独的站会，缺乏日常互动将我们推向了孤岛。我们最终开始做出相互矛盾的决定。我有另一个机会再次在岸上工作，并且有机会与其他团队面对面交流。日常互动让我们变得更好，并对我们的关系产生了积极影响，所以当我再次远程工作时，我们有了共同的理解和更好的融洽关系。我们能够更好地简化我们的讨论，并且我们更好地理解彼此的担忧。

Because we had separate stand-ups, the lack of day-to-day interaction pushed us into silos. We eventually started to make conflicting decisions. I had another opportunity to work onshore again and I had face time with the other team. Daily interactions made us gel better and had a positive impact on our relationship so that when I worked remotely again, we had a shared understanding and better rapport. We were able to streamline our discussions better, and we better understood each other’s concerns.

到项目结束时，我学到的重要教训是确保核心团队在分裂成较小的分布式子团队之前一起工作一段快速启动期。在同一地点共度时光可以建立相互信任和信心。反过来，信任和信心使讨论更有成效，无论是面对面还是通过电话。如果我们早点这样做，我们就可以避免很多痛苦。

By the end of the project, the key lesson I had learned was to ensure that a core team works together for a jumpstart period before splitting into smaller, distributed sub-teams. Spending time together in the same location builds mutual trust and confidence. Trust and confidence, in turn, makes discussions more productive, whether face to face or over the phone. If we had done this earlier, we could have avoided a lot of pain.

你去哪里寻求支持？

Where do you go for support?

我从不同的地方获得支持，这取决于我必须面对什么样的挑战。

I draw support from different places, depending on what sort of challenge I have to face.

面对技术挑战，例如验证团队提出的解决方案或更多行业范围内接受的解决方案，我从以下地方寻求帮助：

With technical challenges, such as validating solutions that the team proposes or more industry-wide accepted solutions, I seek help from the following places:

• 在我当地的社区举行聚会和讨论。参加与技术挑战相关的特定活动是一个很好的起点。
• Meet-ups and discussions in my local community. Attending specific events related to the technical challenge is a good place to start.
• 我从外部工具或技术社区以及内部软件相关论坛征求意见和建议。
• I ask for opinions and suggestions from external tool or technology communities as well as internal, software-related discussion forums.

我试图通过以下方式拓宽我对技术的看法：

I try to widen my perspective on technology by:

• 在一天开始时阅读 20 分钟的汇总内容，例如HackerNews；红宝石周刊；Zite或Flipboard。我会使用Pocket标记有趣的部分以便稍后阅读，并在一周中有更多时间时筛选内容。
• Reading 20 minutes of aggregated content at the start of the day such as HackerNews; Ruby Weekly; Zite, or Flipboard. I mark interesting bits for reading later using Pocket and I sift through the content when I have more time during the week.
• 我将最有趣的文章通过电子邮件发送给团队，并将它们标记为“开发者垃圾邮件”。我经常收到对我发出的文章的反驳和不同观点。
• I email the most interesting articles to the team, marking them as “Developer Spam”. I often receive counter-arguments and different perspectives on the articles I send out.
• 我阅读了关于我想加深理解的主题的书籍和文章。
• I read books and articles on subjects where I want to develop a deeper understanding.

作为 Tech Lead，有时您必须传达坏消息或反击给团队施加压力的非技术人员。在离岸环境中，与客户的咨询受到可用通信模式的限制。虽然视频通话是讨论和解决问题的好方法，但并非总是可行。我不足的一个关键领域是当我不同意某件事（通常是技术方面）时，我会退缩。我避免通过电子邮件开始讨论，因为来回讨论问题往往会使关键讨论陷入困境。在电话讨论中，我发现我没有机会强调我的观点。当我无法与预期的各方讨论我的观点时，我会接触在岸团队成员以传达我的意见，他们帮助将其传达给客户开发人员社区。

As a Tech Lead, you sometimes have to deliver bad news or push back at non-technical people who put pressure on the team. In the offshore setting, consulting with the client is restricted by the modes of communication available. While video calls are a great way to discuss and thrash out issues, they are not always possible. One key area where I fall short is in pushing back when I don’t agree with something (usually technical aspects). I avoid emails to start the discussion, because batting things back and forth tends to leave the crucial discussion in limbo. During a phone discussion, I find I don’t get chance to emphasise my point. When I can’t discuss my point with the intended parties, I approach onshore team members to convey my opinion and they helped relay it to the customer developer community. My support network in this area is limited and I reached out only to people I know do this well or, specifically, my sponsor.

你的观点改变了吗？

Has your perspective changed?

鉴于没有金卷千秋传世，阐明Tech Lead的职责，我对自己职责的看法是从其他Tech Lead的观察中收集而来的。其中之一就是由我来确保我们作为一个团队编写高质量的代码。当我着手实现这一目标时，由于任务的绝对压倒性，我摔倒在地。结果我确实学到了一些东西。

Given that there is no golden scroll handed down from generation to generation, spelling out the responsibilities of Tech Lead, the notions I had about my responsibilities were gleaned from observations of other Tech Leads. One of these was that it was up to me to ensure that we wrote quality code as a team. And when I set out to achieve that, I fell flat on my face due to the sheer overwhelming nature of the task. I did learn a few things as a result.

每天开始时，我都会花 30 分钟浏览整个团队的 git 提交，寻找需要改进的地方。开始还不错，但是当我们准备好开发人员对并全力运行时，几乎不可能保留所有上下文并客观地为所有内容做出贡献。但是，我开始的方法之一是对特定代码段的 git commit 进行评论，以获得更好的见解。这很快成为项目中每个人的常态：每个人每天都查看提交，提出问题并提出改进建议。这种行为变得病毒式传播，我们设法维持它，即使人们滚下或滚下，它自动提高了整体质量。在“午餐和学习”课程中开发了类似的学习过程，

At the start of every day, I spent 30 minutes browsing through the git commits of the whole team, looking for areas of improvement. It started well, but as we geared up developer pairs and ran full throttle, it became almost impossible to retain all context and contribute to everything objectively. However, one of the ways I started was to comment on a git commit on a specific piece of code to get better insights. This soon became the norm for everyone on the project: everyone looked through commits everyday, asked questions and suggested improvements. This behaviour became viral and we managed to maintain it, even when people rolled off or rolled on, and it automatically improved the overall quality. A similar learning process developed in “Lunch and Learn” sessions, which helped us to improve on pieces of code and technologies that we didn’t all know well.

“午餐和学习”会议有时被称为“Brown Bag”会议，团队在午餐时围绕一个重点主题或演示进行讨论。这些课程可以在相对轻松的氛围中快速学习或探索。 “Lunch and Learn” sessions are sometimes called “Brown Bag” sessions, where the team has lunch with a discussion around a focused topic, or presentation. These sessions enable rapid learning or exploration in a relatively casual atmosphere.

到最后，我已经体验到 Tech Lead 的角色更多是为了促进团队，而其他一切都作为副作用落到实处。如果我一开始就意识到这一点，我会专注于正确的部分。

By the end I had experienced how the role of a Tech Lead was more about facilitating the team and everything else fell into place as a side effect. If I had appreciated that to start with, I would have focused on the right bits.

此外，正如我之前所说，非技术工作的绝对数量和业务在每个决策中必须考虑的优先级改变了我对 Tech Lead 角色的看法。

Also, as I said earlier, the sheer quantity of non-technical work and the priority that business has to take in every decision changed my perspective of the role of Tech Lead.

Priyank 的关键问题：分布式团队的技术负责人需要什么？

Priyank’s key question: What is required from the Tech Lead of a distributed team?

我仍在学习如何处理分布式问题，但我认为关键因素是沟通和建立融洽关系。如果你孤立地工作或沟通不畅，那么很多技术能力在岸上是看不到或看不到的。为了保持有效的沟通，我不得不加强并掌控那些不属于我日常工作或计划迭代的可操作的事情，纯粹是为了表现出联系和贡献的意愿。这使内部和外部团队之间的关系走上正轨，尽管距离遥远，但对成功大有帮助。

I am still learning how to deal with being distributed, but I think the key factors are communication and building rapport. A lot of technical capabilities aren’t seen or perceived across the shore if you work in isolation or don’t communicate well. To maintain effective communications, I have had to step up and take ownership of actionable things that weren’t part of my day-to-day work or planned iteration, purely to show willingness to connect and contribute. This gets the relationship between the internal and external team off on the right foot and goes a long way to being successful, despite the distances.

普里扬克的背景故事

Priyank’s background story

Priyank 在获得信息技术专业的工程学位后于 2004 年开始从事该行业。他主要在离岸环境中工作，他的大部分团队都以分布式方式工作。他曾为零售、保修和旅游等广泛行业的客户工作，并且喜欢学习不同领域。

Priyank started in the industry in 2004 after graduating with an Engineering degree majoring in Information Technology. He has mostly worked in an offshore context with most of his teams working in a distributed manner. He has worked for clients in a wide range of industries including retail, warranty, and travel and enjoys learning about different domains.

最近，他第一次担任分布在美国和印度的约 20 人团队的技术主管。

He recently played the Tech Lead role for the first time for a team of approximately 20 people distributed across the US and India.

更大的图景——Suchit Puri

The Bigger Picture – Suchit Puri

Tech Lead 的角色有什么惊喜吗？

Does the role of Tech Lead hold any surprises?

作为一名开发人员，我发现我的大部分注意力都集中在以尽可能最好的方式完成功能上。我关心的是正确的设计和保持适当水平的自动化测试覆盖率。

As a developer, I found most of my focus was on completing a feature in the best possible way. I was concerned with the right design and maintaining an appropriate level of automated test coverage.

随着我获得更多经验，我的注意力转移到了应用程序的整体设计上；现在我必须考虑应用程序如何适应整个应用程序生态系统。

As I gained more experience, my focus shifted to the overall design of an application; now I have to consider how the application fits into the whole ecosystem of applications.

作为 Tech Lead，您有更多机会参与开发以外的活动，例如项目启动、讨论即将到来的业务优先事项的会议，以及更早获得支持技术解决方案的机会。

As a Tech Lead you have more chance to participate in activities beyond development such as a project initiation, meetings to talk about upcoming business priorities, and earlier opportunities to champion a technical solution.

我觉得 Tech Lead 必须平衡与业务的互动，同时在团队中保持一致的技术方向。在离岸项目中保持这种平衡更为重要，因为当人员分散时，沟通渠道会受到限制。

I feel a Tech Lead has to balance interactions with the business with maintaining a consistent technical direction in the team. Maintaining this balance is even more important in an offshore project because communication channels are limited when people are distributed.

优点和缺点

The pros and cons

我最喜欢 Tech Lead 角色的一点是，你有机会设计复杂的系统，解决有趣的业务问题，同时还能开发设计良好的代码。我觉得编写代码是成为 Tech Lead 的重要组成部分，因为只有在与团队一起处理代码库时才能学到某些课程。

The thing that I like most about the Tech Lead role is that you get the chance to design complex systems, solve interesting business problems, and still develop well-designed code. I feel writing code is an essential part of being a Tech Lead because there are certain lessons you learn only when you are working with the team on a codebase.

这个角色的另一个好处是你有更多机会与客户互动。我发现与客户进行更多互动可以为解决和改进业务和技术问题创造更好的见解。在离岸项目中，交流技术和业务解决方案可能具有挑战性，但这对成功至关重要。

Another great thing about this role is you get more opportunity to interact with the client. I find having more interaction with the client creates better insights for solving and improving business and technical problems. In an offshore project it can be challenging to communicate technical and business solutions, but it is critical to success.

我唯一不喜欢 Tech Lead 角色的地方是花很多时间开会。来自纯技术背景，我花了一段时间才适应这一点，因为时间管理不是你作为开发人员经常练习的技能。

The only thing I don’t like about the Tech Lead role is spending lots of times in meetings. Coming from a purely technical background, it took a while for me to adjust to that, because time management is not a skill you practice much as a developer.

有什么准备建议吗？

Any preparation advice?

我不确定你能做些什么来真正做好准备，因为 ThoughtWorks 中的机会是动态的，而且非常有背景。我在工作中学到的唯一技能是将精力集中在我项目的正确领域。

I am not sure there is anything you can do to prepare really, as the opportunities in ThoughtWorks are dynamic and extremely contextual. The only skill I learned on the job was to focus energies on the right areas of my project.

我本可以花更多时间学习端到端的系统架构。

I could have spent more time learning about architecting systems end to end.

你去哪里寻求支持？

Where do you go for support?

技术论坛、办公室小组和技术会议中的讨论给了我很大的信心。围绕技术的非正式聚会教会了我很多东西。我遇到了许多经验丰富的开发人员，我发现他们在技术方面的经验特别丰富和令人兴奋。

Discussions in tech forums, office groups, and tech meet-ups gave me a lot of confidence. Casual meet-ups around technology taught me a lot. I met many experienced developers, and I found their experiences with technology especially informative and exciting.

你的观点改变了吗？

Has your perspective changed?

我认为当你担任 Tech Lead 角色时，你肩上的责任会更多。您对项目的总体设计、代码质量、可测试性和其他方面感到更加负责。

I think there is a lot of more responsibility on your shoulders when you step into the Tech Lead role. You feel more accountable for the overall design, code quality, testability, and other aspects of the project.

我现在当然更多地考虑未来，特别是针对最终目标而不是一些中间目标设计解决方案。

I certainly think more about the future now, particularly designing solutions aimed at the end goal instead of some intermediate one.

我一直在寻找新的技术、方法和想法来让你和你的团队的生活更轻松。

I am constantly looking for new technology, approaches and ideas to make your life and your team’s life easier.

Suchit 的关键问题：Tech Lead 应该具备多少项目管理知识？

Suchit’s key question: How much project management knowledge should a Tech Lead have?

根据我们目前的招聘率，我发现自己身边有很多研究生开发人员和业务分析师。我发现在很多情况下，客户会问很多关于故事点、速度和进度的问题。在这种情况下，我觉得理解项目管理概念对于与客户建立牢固的关系至关重要。

With our current hiring rate, I find myself with a lot of graduate developers and business analysts. I find myself in many situations where the client asks many questions about story points, velocity, and progress. In situations like this, I feel understanding project management concepts are critical to building a strong relationship with the client.

Suchit的背景故事

Suchit’s background story

Suchit 作为一名应用程序开发人员工作了大约五年，从一家电信公司开始构建一个应用程序来为呼叫中心座席路由呼叫。此后，他在一家产品公司工作，目前担任 ThoughtWorks 的顾问。他最近的团队由 12 人组成，其中 8 人是开发人员，他担任该团队的 Tech Lead 将近一年。

Suchit has worked as an application developer for about five years, starting with a telecommunications company building an application to route calls for call-centre agents. Since then, he has worked with a product company and currently works as a consultant for ThoughtWorks. His most recent team is made up of 12 people, of whom eight are developers and he has played the Tech Lead for this team for almost a year.

更少的编码，更多的责任——David 'Bucky' Schwarz

Less Coding, More Responsibility – David ‘Bucky’ Schwarz

Tech Lead 的角色有什么惊喜吗？

Does the role of Tech Lead hold any surprises?

最让我吃惊的是，我写的代码少了很多，即使有人过渡到 Tech Lead 角色也是如此。我花了更多的时间帮助其他人解决他们的问题、规划和帮助软件的整体设计。有一天，我尊敬的一位开发人员要我帮助他进行一项新功能的后端设计。意识到高级开发人员可能会向我寻求技术帮助，我感到非常惊讶。直到我最终做出最终决定的那一刻，它才真正沉没。

The thing that surprised me most was how much less code I write, even as someone transitioning into a Tech Lead role. I’m spending a lot more time helping other people with their problems, planning, and helping with the overall design of software. One day, a developer that I respect asked me to help him with the backend design of a new feature. It came as a huge surprise to realise that senior developers might look to me for technical help. It hadn’t really sunk in until that moment that I was ultimately making the final decisions.

优点和缺点

The pros and cons

我喜欢直接影响特定项目的开发风格、任务和方向。我喜欢指导初级团队成员，并在需要时提供知识和帮助；能够分享通过经验和我过去犯的愚蠢错误获得的知识是件好事。我喜欢我的队友可以依靠我来处理他们需要处理的事情。我喜欢我可以将许多不同的评论和想法过滤并提炼成所需的基本部分。

I like having a direct influence on the development style, tasks, and direction of a particular project. I enjoy mentoring junior team members, and provide knowledge and help when needed; it is good to be able to share knowledge gained through experience and dumb mistakes I’ve made in the past. I like that my teammates can depend on me to take care of things they need taken care of. I like that I can filter and distil down many disparate remarks and ideas into the essential pieces needed.

我不喜欢的是，我对项目方向的影响不再通过我写的代码来表达。我花在会议上的时间比我想的要多，经常听人们一遍又一遍地说同样的话。有时我很难看到一个初级成员在我可以在一小部分时间内完成的任务上挣扎和失败，但我不能干预，因为他们需要从错误中吸取教训。

What I dislike is that my influence over the direction of the project is no longer expressed through the code I write. I spend more time in meetings than I would like, often listening to people say the same things over and over again. I sometimes find it difficult to watch a junior member struggle and fail at a task that I could finish in a fraction of the time, but I can’t intervene because they need to learn from their mistakes.

有什么准备建议吗？

Any preparation advice?

我认为花更多时间指导初级成员会让我更好地为这个角色做好准备。我觉得我团队中最多产的编码员和最少产的编码员之间存在巨大差异。与最多产的人打交道既简单又愉快，而与最少产的人打交道则需要很大的耐心和指导。

I think that spending more time mentoring junior members would have better prepared me for the role. I feel that there is a vast difference between the most prolific coder on my team and the least. Dealing with the most prolific is simple and enjoyable, while dealing with the least prolific requires much patience and coaching.

我也希望更多地练习对人说不。当有人对他们的工作充满热情并依赖你提供他们想要的东西时，这很难，但现实世界的限制迫使你拒绝他们。

I would also have liked more practice at saying no to people. It’s hard when someone is passionate about their job and depending on you to deliver what they want, but real-world constraints force you to tell them no.

你去哪里寻求支持？

Where do you go for support?

我的经理一直是我的支持和灵感来源。他是我共事过的最好的经理之一，他一直在指导我。我喜欢阅读Rands in Repose作为巩固我思想的一种方式，并作为新想法和看待问题的新方法的来源。我的经理推荐了几本关于管理软件开发人员的书。这些包括：

My manager has been a good source of support and inspiration. He’s one of the best managers I’ve ever worked for, and he’s been coaching me along the way. I enjoy reading Rands in Repose as a way to consolidate my thoughts, and as a source of new ideas and new ways of looking at issues. My manager has recommended a few books on managing software developers. These include:

• 管理人类：软件工程经理的辛辣幽默故事
• Managing Humans: Biting and Humorous Tales of a Software Engineering Manager
• 胡萝卜加大棒：释放激励的力量来完成事情
• Carrots and Sticks: Unlock the Power of Incentives to Get Things Done
• 目标风险 2：安全与健康的新心理学
• Target Risk 2: A New Psychology of Safety and Health
• 敏捷估算和规划
• Agile Estimating and Planning
• 规划极限编程
• Planning Extreme Programming
• 眨眼：不假思索的思考的力量
• Blink: The Power of Thinking without Thinking

我总是试图储存那些对我有深刻影响的情况，无论是积极的还是消极的。

I always try to store away situations that deeply affected me, both positively and negatively.

你的观点改变了吗？

Has your perspective changed?

从我参加工作开始，父亲就一直在用管理者的眼光来指导我。我觉得我已经明白发生的事情比我的经理所说的要多得多，但直到我担任更大的领导角色之前我才明白到底有多少。我了解到大多数人并不像他们认为的那样善于沟通。我现在明白为什么经理们会路过并询问发生了什么事，以及（通常）如何不应该将其视为对立的。我对组织复杂程度的看法发生了巨大变化。我从来没有完全意识到平衡几十个人的竞争请求是多么困难，更不用说数百个人了。

My father has been coaching me in the perspective of managers since I started work. I feel that I’ve understood that there is a lot more going on than my manager lets on, but I never understood just how much until I moved into a greater leadership role. I’ve learned that most people don’t communicate as well as they think they do. I now understand why managers will swing by and ask what’s going on, and how (usually) it shouldn’t be regarded as antagonistic. My view of how complex an organisation is has changed dramatically. I never fully appreciated how difficult it is to balance dozens of people’s competing requests, much less hundreds.

Bucky 的关键问题：您是否乐于担任 Tech Lead，还是更喜欢其他角色？

Bucky’s key question: Are you happy being a Tech Lead or would you prefer a different role?

是的，我很高兴成为 Tech Lead。我喜欢担任领导职务，尽管一开始会很累、压力很大、神经紧张。

Yes, I’m happy being a Tech Lead. I enjoy being in a leadership position even though it was tiring, stressful and nerve-wracking to start with.

巴基的背景故事

Bucky’s background story

Bucky 17 岁时开始玩弄网站（Flash！），边学边做。他大学毕业，获得计算机科学学位，从事专业编程工作大约七年。他是一个十人团队的软件工程师，该团队为 Etsy 内部使用构建电子邮件营销软件，并正在过渡到技术主管职位。

Bucky started playing around with websites (Flash!) when he was 17 years old, learning as he went. He graduated college with a degree in Computer Science and has been programming professionally for about seven years. He is a Software Engineer on a team of ten that builds email-marketing software for Etsy internal use and is transitioning into the Tech Lead position.

依靠沟通技巧——Stefan Marev

Lean on Communication Skills – Stefan Marev

你如何看待自己的角色？

How do you see your role?

我经常发现自己与团队沟通产品愿景，因为我在公司工作了很长时间，拥有广泛的领域知识，并且花了很多时间与产品经理和总监在一起。因此，我还参加了我们团队在白板上进行的许多领域建模会议——这些技术借鉴自领域驱动设计：解决软件核心的复杂性问题。

I often find myself communicating the product vision to the teams, because I have been with the company for a long time, have extensive domain knowledge, and spend a lot of time with product managers and directors. As a result, I also attend many of the domain-modelling sessions our team conducts at a whiteboard - techniques borrowed from Domain-Driven Design: Tackling Complexity in the Heart of Software.

我还指导项目的技术愿景并领导任何必要的架构更改，例如尝试将“大泥球”域模型分解为更小的分布更好的部分。高质量是这些项目成功的关键，因此我支持围绕自动化测试和其他实现持续交付的实践所做的努力。

I also steer the technical vision for the projects and lead any necessary architecture changes, such as trying to break a ‘big ball of mud’ domain model into smaller parts that are better distributed. High quality is key to the success of these projects, so I champion efforts around automated testing and other practices that enable continuous delivery.

编者注：一个大泥球是一个结构随意、杂乱无章、马马虎虎、胶带和钢丝绳、意大利面条式代码丛林的软件系统。请参阅 Brian Foote 和 Joseph Yoder 的论文“一大团泥”（1997 年）

Editor’s note: A big ball of mud is a software system haphazardly structured, sprawling, sloppy, duct-tape and bailing wire, spaghetti code jungle. See the paper, “A Big Ball of Mud” by Brian Foote and Joseph Yoder (1997)

Tech Lead 的角色有什么惊喜吗？

Does the role of Tech Lead hold any surprises?

这个角色比我预期的更以人为本；最让我吃惊的可能是技术技能的作用很小。我也低估了与分布式团队合作的困难。当您是一名开发人员时，您更容易确定自己在日常工作中的成功程度；更容易获得反馈，因为您的工作成果更加切实。

The role is more people-oriented than I expected; what surprised me most was probably how small a part technical skills play. I underestimated the difficulties of working with a distributed team too. When you are a developer it is a lot easier for you to determine how successful you are on a day-to-day basis; it is easier to get feedback because the results of your work are more tangible.

另一件让我感到惊讶的事情是化学反应的重要性——人们如何在一个团队中融合在一起——同样，技术技能并不是唯一的因素。始终保持团队士气高涨非常具有挑战性，更重要的是，您有责任找到每个团队成员的驱动力并照顾他们的职业抱负。

The other surprising thing for me was the importance of chemistry - how people fit together in a team - again technical skills are not the only factor. Keeping team morale high at all times can be quite challenging and, more importantly, you are responsible for finding the drivers of each individual team member and looking after their career aspirations.

首先，我必须更多地关注指导、成功交流想法和充分利用每个团队成员。在与 ThoughtWorks 的人一起工作时，我认为很多事情都是理所当然的。例如，我必须让团队关心单元测试并指导测试驱动开发 (TDD) 技能——我从来没有想过需要付出如此多的努力。我想我认为每个开发人员或多或少都是一样的，但我对此的看法是片面的，仅限于我自己！

To begin with, I had to focus a lot more on mentoring, successfully communicating ideas and making the most of each team member. I took a lot for granted while working with people from ThoughtWorks. For example, I had to make the team care about unit testing and mentor test-driven development (TDD) skills - something I’d never thought could take so much effort. I suppose I thought that every developer was more or less the same, but my view on that was one-sided and limited to myself!

优点和缺点

The pros and cons

我最喜欢这个角色的地方在于它具有挑战性，但与开发人员角色的方式不同。它需要我学习和练习不同的技能。指导和领导需要良好的沟通技巧。我学到了很多关于倾听和耐心的重要性，这些技能在与经验不足的团队合作时更为必要。看到团队在我的领导下变得自我组织，我感到非常满足。

What I like most about the role is that it is challenging, but in a different way from the developer role. It requires me to learn and practice different skills. Mentoring and leadership require good communication skills. I learned a lot about the importance of listening and being patient, skills that are even more requisite when working with a team of less experienced people. I gain a lot of satisfaction from seeing the team become self-organising under my leadership.

我也喜欢这个角色的技术挑战，例如培养和交流想法，我经常从在线阅读和关注伟大的技术思想以及参加技术会议和谈话中借鉴这些想法。培训机构SkillsMatter主持其中许多活动。

I also enjoy the technical challenges of the role as well, such as nurturing and communicating ideas, which I often borrow from reading and following great technical minds online and going to technical meet-ups and talks. The training organisation, SkillsMatter hosts many of these.

我不喜欢这个角色的地方在于开发时间较少。我经常开始开发并与其他团队成员结对，但我看不透事情，不得不把它们留给团队来完成。我自然会被拉去参加更多的会议，并且必须与高层经理沟通，这让我用于编码的时间更少了。我想念可以连续几天不间断地编码的时间。

What I dislike about the role is having less time for development. I often start developing and pairing with other team members, but I can’t see things through and have to leave them to the team to finish. I am naturally pulled into more meetings and have to communicate back to high-level managers, which leaves me less time for coding. I miss the time where I can code for days uninterrupted.

我不喜欢这个角色的另一个方面是保护团队免受公司内部组织和政治问题的影响。例如，与象牙塔架构师争论，必须说服他们结对编程的好处并解释这不是浪费时间。另一个挫折是花时间说服经理们企业就绪的技术并不总是最好的解决方案。然而，我确实理解 Tech Lead 角色的这一部分有多重要，因此团队士气保持高涨。

The other aspect of the role I don’t like is protecting the team from organisational and political issues within the company. For example, having arguments with ivory-tower architects, having to persuade them of the benefits of pair programming and explain that it is not a waste of time. Another frustration is time spent convincing managers that enterprise-ready technologies are not always the best solution. I do understand how important this part of the Tech Lead role is, however, and team morale stays high as a result.

有什么准备建议吗？

Any preparation advice?

如果我作为一名开发人员采取更多的主动性，我会为这个角色做好更好的准备。我大部分时间都花在编码上，并专注于代码的质量；我想我应该锻炼一下我的沟通能力。例如，我本可以要求领导回顾或促进讨论和白板会议，而不是仅仅参与并专注于我正在处理的故事和功能中的部分内容。

I would have been better prepared for the role if I had taken more initiative as a developer. I spent most of my time coding and focusing on the quality of the code; I think I should have exercised my communication skills. I could have asked to lead retrospectives or facilitate discussions and whiteboard sessions, for example, instead of just taking part and concentrating only on things that were part of the stories and features that I was working on.

入职新团队成员可能也帮助我发展成为 Tech Lead。当我还是一名开发人员时，我认为这项任务是无聊和重复的，但现在我意识到它可以培养更好的沟通技巧。尽管我发现自己一遍又一遍地解释相同的细节，但我本可以更认真地对待这项任务，并将其视为改善项目各个方面沟通的机会和挑战。

On-boarding new team members might have helped me develop as a Tech Lead as well. When I was a developer, I saw that task as boring and repetitive, but now I realise it develops better communication skills. Even though I found myself explaining the same details over and over again, I could have taken the task more seriously and as an opportunity and challenge to improve communicating all dimensions of the project.

在这方面，结对编程是最能帮助我为成为 Tech Lead 做准备的实践。我发现在准备成为 Tech Lead 时，有人在我身边挑战或确认想法并提供即时反馈对我有很大帮助。

In this respect, pair programming is the practice that most helped me to prepare for being a Tech Lead. I found it a great help when preparing to be a Tech Lead to have someone beside me to challenge or confirm ideas and give instant feedback.

你去哪里寻求支持？

Where do you go for support?

我喜欢我的 ThoughtWorks 团队成员为每个角色提供支持的方式。我工作的公司不是科技公司，应用程序开发是 IT 中相对较小的一部分，所以我们没有相同的设置；没有我可以仰望的技术人员，所以我从我的个人联系人那里寻求支持。我与他们分享想法和问题，以获得早期反馈并帮助解决问题。

I liked the way that my ThoughtWorks teammates had sponsors for every role. The company I work for is not a technology company and application development is a relatively small part of IT, so we don’t have the same kind of setup; there are no technical people I can look up to so I draw support from my personal contacts instead. I share ideas and problems with them to get early feedback and help to resolve issues.

同时，我赢得了工作场所高层管理人员的信任，他们给我时间和支持来实施新想法、尝试新的开发人员实践和活动，让我能够建立自己的团队。我喜欢认为我们已经创建并作为企业内部的小型初创企业工作。

At the same time, I have earned the trust of high-level management in my workplace and they give me the time and support to implement new ideas, try out new developer practices and event allowed me to build my own team. I like to think that we’ve created and work as a small start-up within an enterprise.

互联网和社交网络对我来说非常重要。我发现 Twitter 是向我们行业最伟大的思想家学习的绝佳工具。

The Internet and social networking play an important job for me. I find Twitter an amazing tool for learning from the greatest minds in our industry.

我相信持续改进并努力从尽可能多的来源获得反馈。我经常向团队内外与我共事的各种人征求反馈。

I believe in continuous improvement and strive to get feedback from as many sources as possible. I often ask various people I work with both within and outside the team for feedback.

有什么准备建议吗？

Any preparation advice?

我建议你采取更多主动，充分利用每一种情况，而不是只关注编码。我会尝试参与尽可能多的不同任务，以培养不同的技能。例如，当我还是一名开发人员时，我真正专注于编码测试、功能和一点点构建脚本。我现在意识到，更多地接触生产路径和运营任务也会有所帮助。

I recommend you take more initiative, and make the most of every situation and not focus only on coding. I would try to participate in as many diverse tasks as possible to develop different skills. When I was a developer, for example, I really focused on coding tests, features and a tiny bit of build-scripting. I realise now that having more exposure to path-to-production and operations tasks would have helped too.

Stefan 的关键问题：您如何平衡您的时间并确保您亲力亲为？

Stefan’s key question: How do you balance your time and ensure you stay hands-on?

这将因公司而异，但在像我公司这样的传统 IT 部门，我可以告诉你这不是一件容易的工作。我通过优先级来做到这一点。我优先考虑编码时间和与团队一起度过的时间，而不是参加会议或撰写报告等，即使对于首席信息官 (CIO) 也是如此。

This will vary from company to company, but in a traditional IT department like the one in my company, I can tell you it is not an easy job. I do it through prioritisation. I prioritise time for coding and time spent with the team above going to meetings or writing reports, etc. even for the Chief Information Officer (CIO).

我尽量避免成为项目技术问题的单一联系人。我在团队中培养拥护者，并要求他们在团队内外交流解决方案。我不知道我在这方面有多成功，但我一直在努力！我想找到更多的建议来源。我发现了很多关于在团队内传达目标的好建议，但很少有关于有效地向组织的其他成员传达技术想法的建议。

I try to avoid becoming the single point of contact for technical concerns on the project. I create champions within the teams and ask them to communicate solutions both within and outside the team. I don’t know how successful I am at this, but I keep trying! I’d like to find more sources for advice on this. I have found a lot of good advice on communicating goals within the team, but less on communicating technical ideas effectively to the rest of the organisation.

斯特凡的背景故事

Stefan’s background story

Stefan 自 2005 年以来一直从事技术工作，自从在英国威斯敏斯特大学和里德商业信息 (RBI) 大学开始从事网络技术方面的工作。他加入了 GroupM，在那里他帮助构建基于 Web 的媒体规划和购买系统。

Stefan has worked in technology since 2005 and has worked with web technologies since at the University of Westminster and Reed Business Information (RBI) in the United Kingdom. He joined GroupM where he helps build web-based systems for media planning and buying.

Stefan 一直对敏捷方法论和工程实践充满热情，并在与 ThoughtWorks 的顾问团队合作时深受影响。他目前领导着三个小团队，其中两个在近岸，他与第二个 Tech Lead 密切合作，以在他轮换到另一个团队时提供连续性。

Stefan has always had a passion for agile methodologies and engineering practices and was influenced greatly by working with a team of consultants from ThoughtWorks. He is currently leading three small teams, two of which are near-shore where he works closely with a second Tech Lead to provide continuity when he rotates to a different team.

从业者

Practitioners

“智慧来自经验。经验往往是缺乏智慧的结果。” - 特里普拉切特

“Wisdom comes from experience. Experience is often a result of lack of wisdom.” - Terry Pratchett

在这一部分中，我采访了担任该职位多年或在多个团队中工作过的 Tech Leads。我请他们分享自己的故事、面临的挑战以及随着时间的推移发现的智慧。他们在广泛的行业、各种规模的团队中分享经验，并因此吸取了广泛的经验教训。

For this section I interviewed Tech Leads who have worked in the role for a number of years or across a number of teams. I asked them to share their own stories, the challenges they faced, and the wisdom they found over time. They share their experiences across a wide range of industries, a wide range of team sizes and, as a result, a wide range of lessons learned.

由于角色跨越多个维度，有效的时间管理变得更加重要，因此我要求每个人分享他们自己的方法。他们描述了在哪里可以找到时间、如何确定任务、委派策略，最重要的是，如何在编写代码和兼顾其他职责之间保持微妙的平衡。我将他们的回答分为四个主题：

With a role split across several dimensions, effective time-management becomes even more important, so I asked each person to share their own approach. They describe where to find time, how to identify tasks, strategies for delegation and, most importantly, how to maintain the delicate balance of heads-down time in code and juggling their other responsibilities. I grouped their responses into four themes:

1. 人们
2. People
3. 技术主管的技术
4. The Tech of a Tech Lead
5. 桥接业务与技术
6. Bridging Business with Tech
7. 你
8. You

我觉得这四个主题代表了 Tech Lead 角色的不同方面，并与不同人的回应产生了强烈共鸣。我对这些主题中的每一个都提供了简短的评论，总结了人们的反应并添加了我作为 Tech Lead 的经验中的观察。

I feel these four themes represent different facets of the Tech Lead role, and resonate strongly with the responses from different people. I provide a brief commentary for each of these themes, summarising people’s responses and adding observations from my own experience as a Tech Lead.

人们

People

人和团队有着千丝万缕的联系。没有人就没有团队，把一群人变成一个团队是需要付出努力的。

People and teams are inextricably linked. A team does not exist without people, and it takes effort to turn a set of people into a team.

“一群人并不能组成一个团队。它只作为一个群体存在。团队是一群为共同目标而努力的人。一个有效的领导者会让人们朝着这个目标前进。” - 匿名的

“A set of people does not make a team. It only exists as a group. A team is a set of people working towards a common goal. An effective leader aligns people towards that goal.” - Anonymous

保持技术基础

Remaining Technically Grounded

当开发人员第一次担任 Tech Lead 的角色时，他们的注意力几乎完全集中在技术方面。一些开发人员将 Tech Lead 角色解释为是困难技术选择的最终决策者，或者专注于技术上最困难的问题。

When a developer first moves into the role of Tech Lead, their focus will be almost exclusively on the technical aspects. Some developers interpret the Tech Lead role as being the final decision maker on difficult technical choices or as focusing on the most technically difficult problem.

这些采访揭示了一种截然不同的看法。是的，Tech Lead 必须具备技术能力，因为这有助于与人建立尊重和融洽关系，但是 Tech Lead 不一定是技术上最好的，而且在许多情况下，不一定拥有团队中最深厚的技术技能.

These interviews reveal a very different take. Yes, a Tech Lead must be technically competent, since this helps build respect and rapport with people, however the Tech Lead does not necessarily need to be the best technically and, in many cases, does not necessarily have the deepest technical skills on the team.

寻找和培养优秀人才

Finding and Developing Good People

没有人会着手为他们的团队寻找平庸的人。每个 Tech Lead 都会说他们雇用了优秀的人才。Tech Leads 自然是面试过程的一部分，寻找文化契合度、能力和积极的学习态度。然而，在当今充满活力的劳动力市场上，及时找到理想的人选是很困难的。

No one sets out to find mediocre people for their team. Every Tech Lead will say they hire good people. Tech Leads are naturally part of the interview process, looking for cultural fit, aptitude, and a positive attitude to learning. However, finding the ideal candidate in a timely fashion is difficult in today’s dynamic labour market.

除了寻找优秀人才外，高效的 Tech Lead 还同样关注团队中不断发展的开发人员。一种常见的做法是与每个开发人员进行一对一的会面，以了解他们的兴趣所在、激励他们的因素以及他们认为自己的优势所在。有了这些信息，技术负责人就会不断寻找方法来匹配整个团队的兴趣和机会。本节中的一位受访者谈到将技能和经验的结合视为一种团队力量。

In addition to finding good people, the effective Tech Lead focuses equally on growing developers in their team. A common practice is to meet one-on-one with each developer to find out what their interests are, what motivates them and what they consider their strengths to be. With this information, the Tech Lead constantly seeks ways to match interests and opportunities across the team. One interviewee in this section talks about appreciating the mix of skills and experience as a team strength.

例如，一个人可能认为一项任务微不足道，因为他们过去曾处理过许多类似的问题。对于另一个人来说，同样的任务可能会非常有趣，因为这是他们需要解决的一种新型问题。

For example, a task may be perceived trivial by one person because they have worked on many similar problems in the past. For another person, this same task could be extremely interesting because it is a new type of problem for them to solve.

随着人们的成长和学习，跟踪人们发现有趣的东西会随着时间的推移而演变。Tech Lead 跟上这些变化的唯一方法是足够频繁地询问人们。

Keeping track of what people find interesting evolves over time as people grow, and learn. The only way a Tech Lead can keep up with these changes is to ask people frequently enough.

技术负责人通过鼓励开发人员跳出“仅仅编程”并在软件开发过程中与其他人密切合作来培养他们。开发人员与测试人员更密切地合作，可以更好地理解如何编写更健壮的代码。与最终用户和业务利益相关者更密切合作的开发人员可以更好地理解可以做出哪些可接受的权衡以及需要解决的真正问题。

A Tech Lead grows developers by encouraging them to step outside of “just programming” and work closely with other people in the software development process. Developers working more closely with testers build a better understanding of what it takes to make more robust code. Developers working more closely with end-users and business stakeholders better understand what acceptable trade-offs may be made and the real problem that needs solving.

倾听团队

Listening to the Team

Tech Lead 找机会听取团队成员的意见。一位 Tech Lead 问道：“我的团队是否已经尽其所能？” 当开始一个新团队时，我问自己，“每个人都愿意表达自己的意见吗？” Tech Leads 需要建立安全。

The Tech Lead finds opportunities to listen to the people on their team. One Tech Lead asks: “Is my team set up as well as it can be?” When starting with a new team, I ask myself, “Does everyone feel comfortable expressing their opinion?” Tech Leads need to establish safety.

一旦你创造了安全，你就必须培养整体团队效率的动力。不同的事情会激励不同的人，需要时间来找出每个人想做什么并找到机会去做。倾听是其中的关键。

Once you create safety you must then cultivate motivation for full team effectiveness. Different things motivate different people and it takes time to find out what each person wants to do and find opportunities to do them. Listening is the key to this.

技术主管花在代码上的时间更少，因此他们更依赖来自团队的信息。从开发人员那里提取事实信息可能很困难，因为开发人员习惯性地提出问题的解决方案和意见，而不是事实。你利用良好的提问技巧来提取做出更好决策所需的信息。

Tech Leads spend less time in code, so they rely more heavily on information from the team. Drawing factual information out of developers can be difficult because developers habitually present solutions to problems and opinions rather than facts. You draw upon good questioning skills to draw out the information you need to make better decisions.

欣赏个人优势

Appreciating Individual Strengths

Tech Lead 欣赏每个人为团队带来的不同优势。随着时间的推移，您将认识到这些不同的优势。例如，一些开发人员更善于用更抽象的术语进行思考，而其他开发人员则更注重细节。一些开发人员会更好地进行视觉思考，而其他开发人员则必须通过代码进行最佳沟通。

A Tech Lead appreciates the different strengths that each person brings to the team. Over time you will recognise these different strengths. For example, some developers are better thinking in more abstract terms, whilst others are more detail-oriented. Some developers will be better thinking visually, whilst others must communicate best through code.

优势的差异带来了学习和更好地解决问题的机会，但它们也创造了冲突的机会。Tech Lead 关注团队中的激烈讨论，并在过多的冲突可能会永久破坏团队关系时帮助团队前进。技术负责人不应该害怕促进技术讨论（尤其是激烈的讨论！），以便向前推进。技术负责人很少会介入推翻决定，因为这会剥夺团队成员的权力并引起不满。

Differences in strengths bring opportunities for learning and better problem solving but they also create an opportunity for conflict. The Tech Lead pays attention to heated discussions in the team and helps the team move forward when too much conflict threatens to permanently damage team relationships. Tech Leads should not be afraid to facilitate technical discussions (particularly heated ones!) in order to move forward. Very rarely will a Tech Lead step in to override a decision as this disempowers team members and generates resentment.

团队焦点——艾莉森·罗斯沃恩

Team Focus – Alison Rosewarne

Tech Lead 应该关注什么？为什么？

What should a Tech Lead focus on and why?

团队专注：重要的是团队可以真正专注并知道什么是重要的。这有助于做出良好的决策并确保良好的结果。不同的团队有不同的需求和不同的障碍需要克服以实现专注。

Team focus: it is important that the team can actually focus and knows what is important. This enables good decision-making and ensures good results. Different teams have different needs and different obstacles to overcome to achieve focus.

我担心团队参与度，并希望每个人都受到他们所做工作的挑战。花时间在一对一上通常是衡量兴趣和热情的最佳方式。

I worry about team engagement and want everyone to be challenged with the work that they do. Spending time on 1-to-1s is generally the best way to gauge interest and enthusiasm.

作为 Tech Lead，您遇到的最大挑战是什么？

What has been your biggest challenge as a Tech Lead?

以敏捷的方式与离岸开发团队合作是我作为 Tech Lead 经历过的最具挑战性的情况。人们很容易将走廊谈话视为理所当然；当每个人都在同一地点，在相同的环境中工作时，更容易吸收偶然的上下文。

Working with an offshore development team in an agile manner has been the most challenging situation I’ve experienced as a Tech Lead. It is easy to take corridor conversations for granted; it is easier to absorb incidental context when everyone is co-located, working in the same environment.

处理分布式团队需要不断了解情况。需要更多时间来确保远程团队跟上本地决策的速度，并且您需要使用任何可用的技术来缩短距离并提高通信带宽。Skype 等临时通信工具优于电子邮件或事后文档。

Handling a distributed team requires constant awareness of the situation. More time is needed to ensure the remote team is kept up to speed with decisions made locally and you need to use whatever technology is available to decrease the distance and improve communication bandwidth. Ad hoc communication tools such as Skype are better than email or after-the-fact documentation.

有什么时间管理技巧吗？

Any time-management tips?

我是一个专门的列表制作者。每周我都会回顾优先事项并计划至少三件我每天想要完成的事情。了解相互竞争的优先级很重要，这样可以管理任何中断。有些工作必须完成（推迟计划的任务），而其他工作可以推迟。我会记录意想不到的工作以供日后审查。有时需要在我的日历中预订时间或在家工作，以确保可以不间断地完成需要专注的任务。

I am a dedicated list maker. Each week I review the priorities and plan at least three things that I want to achieve each day. It is important to understand competing priorities so any interruptions can be managed. Some work has to be done (deferring planned tasks), while other work can be deferred. I keep track of unexpected work for later review. Occasionally booking time in my calendar or working from home is necessary to ensure tasks requiring focus can be completed without interruption.

您如何在编写代码和处理其他问题之间取得适当的平衡？

How do you strike the right balance between writing code and dealing with other issues?

我写的代码没有我想写的那么多；自己写代码和做其他事情的比例大约是 20/80。这可能会根据项目所处的阶段而改变。我不得不承认，与团队成员结对并为他们编写的代码提供指导比我自己编写所有代码更有效率。

I don’t write as much code as I would like to; the split between writing code myself and doing other things is about 20/80. This can change depending on what stage a project is at. I have had to accept that it is more productive to pair with team members and provide guidance about the code they produce rather than writing all the code myself.

艾莉森的关键问题：什么技能对技术领导力帮助最大？

Alison’s key question: What skill helps most with tech leadership?

委派能力和良好的沟通技巧对于技术领导至关重要。在这两者中，我认为良好的沟通技巧是最有帮助的。作为 Tech Lead，您需要针对技术和非技术受众量身定制您的沟通方式。

The ability to delegate and good communication skills are essential to technical leadership. Of these two, I would say good communication skills are the most helpful. As a Tech Lead you need to tailor your communication for both technical and non-technical audiences.

对于技术听众，您需要知道自己在说什么；你不能伪造它，正如人们可以看出的那样。重要的是总结细节并在小组中达成共识。对于非技术受众，您需要将不同方法和权衡所涉及的努力转化为对体系结构选择的支持，并将时间花在技术活动上，例如减少技术债务的努力。

For technical audiences you need to know what you are talking about; you cannot fake it, as people can tell. It is important to summarise detail and achieve consensus amongst the group. For non-technical audiences you need to translate the effort involved in different approaches and trade-offs to gain support for architectural choices and spending time on technical activities such as effort in reducing technical debt.

艾莉森的背景故事

Alison’s background story

Alison 曾在 REA Group 的商业团队担任技术主管两年。从澳大利亚墨尔本皇家墨尔本理工大学毕业后，她开始在 IT 行业工作。在过去的十年里，她在许多行业工作过，例如游戏、养老金、国防和保险。

Alison has worked as Tech Lead for the Commercial team at REA Group for two years. She started working in the IT industry after graduating from RMIT University in Melbourne, Australia. For the last ten years she has worked across many industries such as gaming, superannuation, defence, and insurance.

在过去六年中，她根据咨询业务断断续续地领导技术团队。她的核心开发经验是 Java/J2EE，最近她一直在使用 Ruby 和相关的 Web 框架进行开发。

She has lead technical teams on and off over the last six years depending on the consulting engagement. Her core development experiences were in Java/J2EE and more recently she has been developing with Ruby and associated web frameworks.

团队超越自我——汉弗莱·埃尔顿

Team over Self – Humphrey Elton

Tech Lead 应该关注什么，为什么？

What should a Tech Lead should focus on and why?

我希望领导专业而不矫饰的人。我不希望监督所有代码。但是，我确实希望团队能够一起工作。对我来说，开发人员的人际关系和沟通技巧与代码编写一样重要，甚至可能更重要。团队中能力的混合意味着枪支必须帮助初级开发人员并给他们学习自己的空间。我对简单甚至低效的代码的问题更少。

I expect to lead people who are professional without pretensions. I do not expect to oversee all code. I do, however, expect teams to work together. For me, a developer’s skills with personal relationships and communication are as important as code writing, possibly more so. A mix of abilities in the team means that the guns have to help junior developers and give them space to learn themselves. I have fewer issues with simplistic, and even inefficient code.

在我的软件开发领域，内存很便宜，CPU 很便宜，复杂的代码维护成本太高，所以不要让我写磁盘子系统！

In my area of software development, memory is cheap, CPU is cheap and complex code is too costly to maintain, so do not ask me to write a disk subsystem!

我尽量留意来自任何团队的噪音。在一种极端情况下，太多的谈话可能表明人们效率太低，团队没有做出决定，或者他们可能玩得太开心了。另一个极端，太安静可能意味着每个人都在朝着自己的方向前进，代码不会很好地结合在一起，或者正在酝酿个性问题。

I try to keep an ear out for the noise coming from any team. At one extreme, too much talking might indicate people being too unproductive and that the team are not making decisions, or they might be having just too good a time. At the other extreme, too quiet might mean everyone is heading in their own direction and the code will not combine well, or that there are personality issues brewing.

讨论是好的，但对所有人来说都是无用的和令人沮丧的，除非它的重点是选择一个结果。

Discussion is good but unproductive and frustrating for all unless its focus is choosing an outcome.

作为 Tech Lead，您遇到的最具挑战性的情况是什么？您是如何处理的？

What has been your most challenging situation as a Tech Lead and how did you handle it?

我最具挑战性的情况是管理一个由一些技术非常优秀的开发人员和一些初级开发人员组成的混合团队。那支球队有很多问题，其中至少有两个不同的经理。团队成员之间完全不一致。部分团队的代码风格截然不同，因为有些是 Java 开发人员，但需要大量 Javascript，并且没有一致的方法来实现新功能。“大师”也会写代码，把“单元测试”留给后辈。

My most challenging situation was managing a mixed team of some technically very good developers and some juniors. That team had a lot of issues, of which having two different managers was the very least. The team members were completely at odds with each other. Parts of the team had significantly different code styles, because some were Java developers, but a lot of Javascript was required and there was no consistent approach to implementing new features. The “gurus” would also write code, leaving the “unit tests” to the juniors.

我们举行了一次会议，我参加了会议只是因为一位经理不在。我们把所有已知的问题都摆在桌面上，让会议达到了一个脆弱但甜蜜的点，我在那里停止了它。然后我们给团队几分钟时间来解决每个问题，如果他们无法做出决定，我会介入做出决定。我只需要做几个；团队解决了剩下的问题。

We held a meeting, in which I was involved only because one manager was away. We put all known issues on the table and allowed the meeting get to a fragile, but sweet point, where I stopped it. We then gave the team a couple of minutes to resolve each problem, and if they couldn’t reach a decision, I would step in to make one. I only had to do a couple; the team worked the rest out.

我确保团队中的每个人在某处都有发言权。没有比一个好想法被忽视，或者其代码在一周内被重构的初级人员更不高效的了。我只坚持一项：如果它有效，那就离开它继续前进。

I ensured that everyone in the team had a say somewhere. There is no one less productive than a junior whose good idea gets ignored, or whose code gets refactored within a week. I only insisted on one item: if it works, then leave it and move on.

你管理时间的秘诀是什么？

What are your secrets to managing time?

作为 Tech Lead，您希望您的团队富有成效。

As a Tech Lead you want your team to be productive.

你的时间只有一个人的价值。你的团队是那个的 n 倍。你的重点应该放在他们的生产力上。

Your time is only one person’s worth. Your team’s is n times that. Your focus should be on their productivity.

尝试找到良好团队时间的平衡点，同时让每个人都有自己的最佳时间。我在下午晚些时候效率最高。如果有人打扰我，我会设法让他们在第二天早上安排时间。

Try to find the balance of good team time, while letting each have their own best time. I am most productive late in the afternoon. If people interrupt me then I try to get them to organise a time the next morning.

因为我的孩子，我周三下午休息。管理层讨厌它，但它给了团队时间来自我负责。有时我会去接孩子，然后远程登录并完成任务，有时则不会。

I have Wednesday afternoons off because of my kids. Management hates it, but it gives the team time to be self-responsible. Sometimes I pick up the kids, then log in remotely and finish stuff, other times not.

你可能会发现你无法选择所有符合你技能的任务，因为中断意味着你无法保证它们会按时完成。你只需要对你所承担的事情更加小心。

You will probably find you cannot choose all the tasks that match your skills, because interruptions mean you can’t guarantee they will be completed on time. You just have to be more careful about what you take on.

您如何找到编写代码和处理其他问题的平衡点？

How do you find the balance writing code and dealing with other issues?

平衡编写代码和处理其他问题是一个持续的冲突，而且永远都是。必须尽早处理中断。如果你不解决它们，它们就会堆积起来淹没你。我有淘气的日子，我真的只想编码，但我后来才付钱。偶尔放纵一下自己！

Balancing writing code and dealing with other issues is a constant conflict, and always will be. Interruptions must be dealt with sooner rather than later. If you do not address them, they will stack up and swamp you. I have naughty days when I really just want to code, but I pay for it later. Indulge yourself occasionally!

我尝试自己处理很多问题，但如果我可以将问题或决定委托给团队中的某个人，那么我会的。我不记得我最后一次推翻他们的决定是什么时候。他们的决定可能不是我会做出的决定，但它几乎总是足够好。不要全部做；但也不要全部委派。我尽量不要对我所做的事情和我委托的事情制定太多规则。我尝试一些事情，犯一些错误，然后从中吸取教训。

I try to deal with a lot of the issues myself, but if I can delegate problems or decisions to someone in the team, then I will. I cannot remember when I last overrode what they decided. Their decision may not be the one that I would have made, but it is almost always good enough. Do not do it all; but do not delegate it all either. I try not to have too many rules about what I do versus what I delegate. I try things, make a few mistakes, and learn from them.

决定成为 Tech Lead 离编码只有一步之遥，除非你愿意做更长的时间，或者很明显你没有直线管理。我从来没有那样工作过，也不认为这是可能的。

Deciding to be a Tech Lead is a step away from coding, unless you are willing to do longer hours or it is really clear that you have no line management. I have never worked that way and do not think that it is possible.

这个角色涉及与人打交道，比我意识到的要多。如果您不想与人打交道或认为这不重要，那么 Tech Lead 角色可能不适合您。您需要积极建立关系并关注团队内部的关系。

The role involves dealing more with people than I realised. If you do not want to have to deal with people or do not think it is important, then the Tech Lead role may not be for you. You need to actively build relationships and have on eye on the relationships within the team.

我没有去探索，也没有在代码中尝试不同的东西，而我以前作为开发人员做的更多。

I do not get to explore, or try different things in code that I used to do much more as a developer.

汉弗莱的关键问题：它在组织中是一个明智的角色吗？

Humphrey’s key question: Is it a sensible role in an organisation?

可能不会！你的技能没有生产力。你能在什么时候交付什么是不可预测的。该角色距离编码仅一步之遥。每当您真正专注时，就会有人过来打断它。您将不可避免地对自己喜欢的语言感到厌烦，但希望您能够成熟地认识到大多数问题并不是真正针对特定语言的。

Probably not! You are unproductive for your skills. What you can deliver by when is unpredictable. The role is one step away from coding. Whenever you get really focused, someone will come along and interrupt it. You will inevitably get staler in your favourite language, but hopefully you will have the maturity to appreciate that most of the issues are not really language specific.

您必须开始更仔细地阅读所有管理电子邮件；也许甚至开始做一次！当你试图集中注意力时，你必须学会​​把一只耳朵放在房间里。您还必须决定何时介入任何事情。同时，您必须给您的团队空间，并记住在没有 Tech Lead 或其他人参与的情况下解决问题的频率。你变得一半是管理人员，一半是员工。这并不容易，因为你不可避免地站在两边，但又不完全属于任何一方。

You have to start reading all management emails more carefully; maybe even start doing it for once! You have to learn to have one ear on the room, while you are trying to concentrate. You also have to decide when to stick your nose into anything. At the same time, you must give your team space and remember how often problems got solved without a Tech Lead or someone else getting involved. You become half management, half grunt. It is not easy as you are inevitably on both sides, yet in neither camp completely.

我想这个角色就像军队中的下士或中士。人们服从权威，通常是在完全无能的情况下，你必须学会​​何时使用它。找到你内心的锡锅暴君的风格。明智地使用它。

I imagine this role is like that of a corporal or sergeant in the army. People obey authority, often in the face of complete incompetency, and you must learn when to use it. Find the style of your inner tinpot tyrant. Use it wisely.

您不可避免地要管理团队。你需要决定团队应该自己决定什么。例如，说我真的很讨厌代码风格讨论是轻描淡写的，所以我让团队选择！他们比你还要生活在里面，但只给他们两分钟的时间来讨论！它可以持续更长时间，但您始终拥有否决权！

Inevitably you are managing the team. You need to decide what the team should decide for themselves. It would be an understatememt to say I really hate code style discussions, for example, so I let the team choose! They have to live in it more than you, but only give them two minutes to discuss it! It can go on for much longer, but you always have veto!

汉弗莱的背景故事

Humphrey’s background story

尽管从事开发工作 20 年并处理 Fortran、OpenVMS-TPU（虚拟内存系统-文本处理实用程序）等技术，但汉弗莱认为自己不像大多数人那样是“技术”技术主管。他最近使用 Java、Flex、PHP 和 Python。

Humphrey considers himself less of a “technical” Tech Lead than most despite working in development for 20 years and dealing with technologies such as Fortran, OpenVMS-TPU (Virtual Memory System-Text Processing Utility). He has more recently worked with Java, Flex, PHP and Python.

代表，代表，代表——杰森·塞尔比

Delegate, Delegate, Delegate – Jason Selby

Tech Lead 应该关注什么？为什么？

What should a Tech Lead focus on and why?

团队动态。一旦你不再专注于成为个人贡献者，团队文化的健康是 Tech Lead 可以极大影响并直接影响团队绩效的最有价值的领域。技术主管可以做很多事情来影响文化和动态。您可以尽早发现并解决内部和外部冲突，指导个人进行技术和行为改进，并清除障碍以防止团队因外部约束而陷入困境。

Team dynamics. Once you stop focusing on being an individual contributor, the health of the team culture is the most valuable area that the Tech Lead can greatly influence and directly affects team performance. There are many things the Tech Lead can do to impact culture and dynamics. You can identify and address internal and external conflicts early, coach individuals on technical and behavioural improvements, and clear roadblocks to keep the team from spinning on external constraints.

作为 Tech Lead，您遇到的最大挑战是什么？

What has been your biggest challenge as a Tech Lead?

我的指导原则之一是尽可能频繁地将关键决策委托给团队。这在处理人事问题时通常是不可能的，但除此之外效果很好。让团队自己做决定可以确保在团队层面的方法和结果所有权方面得到认同，尤其是当事情没有完全按计划进行时。

One of my guiding principles is for key decisions to be delegated to the team as frequently as possible. This is often impossible when dealing with personnel issues, but otherwise it works well. Letting the team own decisions ensures buy-in, both on approach and ownership of outcomes at a team level, especially when things don’t go exactly as planned.

虽然这个原则很好，但在实践中并不总是那么容易坚持。

Although the principle is sound, it isn’t always easy to adhere to in practice.

例如，当我在一家大型消费电子零售商领导团队时，我们正在讨论服务端点的设计。每次呈现网页时不会调用此特定服务，但我们的流量模型预测端点将在大约 50% 的时间内看到流量。以零售商的经营规模，这仍然是一个可观的流量。

When I was leading a team at a large consumer electronics retailer, for example, we were discussing the design of a service endpoint. This particular service would not be called every time a web page was rendered, but our traffic model projected that the endpoint would see traffic about 50% of the time. At the retailer’s operating scale, this was still a substantial quantity of traffic.

在两种领先的设计中，一种是计算密集型解决方案，开发时间更短，另一种是开发工作更多，但在请求时几乎不需要计算。我喜欢花费更多开发时间但保证生产性能的解决方案。团队中的许多高级成员希望继续使用针对开发时间优化的解决方案；他们愿意承担性能风险，以便有更多时间专注于其他开发工作，这些工作对于在假期交通高峰之前完成也至关重要。

Of the two leading designs, one was a more compute-intensive solution with less development time and one was quite a bit more development work, but would require almost no computation at request time. I favoured the solution that took more development time but guaranteed production performance. A number of senior members of the team wanted to proceed with the solution that optimised for development time; they were willing to take the performance risk in order to have more time to focus on other development work that was also critical to be completed prior to the rush of holiday traffic.

经过一番辩论后，我们将其付诸表决，并以微弱多数票通过了计算密集型解决方案。我很难接受我的论点不够有说服力。很难抗拒否决团队并强制实施我的解决方案的诱惑。假期来了又去，事实证明团队的决定是正确的；计算密集型解决方案在假期期间一直是一个问题，但它没有造成任何问题，并且有更多时间专注于其他开发优先事项意味着我们解决了其他性能问题，因此可能避免了其他性能问题。

After some debate, we put it to a vote and based on a slight majority, went with the compute-intensive solution. It was hard for me to accept that my arguments weren’t persuasive enough. It was difficult to resist the temptation to overrule the team and impose my solution by fiat. The holiday came and went and the team decision proved right; the compute-intensive solution had been a concern through the holiday period, but it didn’t cause any problems, and having additional time to focus on other development priorities meant that we addressed other performance concerns and so probably prevented other performance problems.

有什么时间管理技巧吗？

Any time-management tips?

我每天很早就到，通常比团队其他人早一个小时。这让我有时间赶上管理任务和电子邮件。完成这些杂务后，当团队开始陆续进入办公室时，我会更加专注。

I get in early each day, usually an hour before the rest of the team. This allows me time to catch up on administrative tasks and email. With those chores out of the way, I’m more focused when the team starts trickling into the office.

另一个主要的时间消耗是回答其他团队的问题。我领导的团队一直是敏捷团队，非常强调低仪式化的协作。这意味着我们鼓励与我们合作的其他团队在有问题或需要时来到我们的开发实验室。问题是，由于我是 Tech Lead 和团队中公认的面孔，我每天都会多次被打扰来回答问题或帮助起草新功能的请求。我通过向我们的团队引入“礼宾”的轮换角色来解决这个问题，他们致力于在特定的一天回答临时请求。我的团队很高兴能更好地了解我们更大的社区，并且可以容忍中断，因为它们会在几周内分散到团队的所有成员中。

Another major time-consumer is answering questions from other teams. The teams I’ve led have been agile teams with a strong emphasis on low-ceremony collaboration. This means we encourage other teams we work with to come to our development lab when they have questions or needs. The problem was that, since I was the Tech Lead and the recognisable face of the team, I was interrupted many times a day to answer questions or help draft requests for new features. I solved this by introducing a rotating role of “Concierge” to our team, who was dedicated to answering drop-in requests on a given day. My team is happy to get get better acquainted with our larger community and the interruptions are tolerable since they’re spread across all members of the team over a few weeks.

您如何在编写代码和处理其他问题之间取得适当的平衡？

How do you strike the right balance between writing code and dealing with other issues?

我努力将会议安排在连续的时间段内，并且只在特定的日子举行。这让我有时间专注于与开发团队一起工作。抽出时间在团队周围并在场是有效和真诚领导的关键。

I work hard to keep meetings scheduled in contiguous blocks and only on certain days. This allows me to have time to be focused and work with the development team. Making time to be around the team and present is key to effective and authentic leadership.

我也毫不留情地选择退出低价值会议或那些缺乏清晰议程的会议。这在所有情况下都是不可能的，但我现在的雇主有一个会议重的文化，如果我不拒绝很多会议，我将没有时间做其他事情。这并没有让我很受欢迎，但我在拒绝时尽量表现得友善。保持专注可以让我和我的团队交付成果。

I’m also merciless about opting out of low-value meetings or those that lack a crisp agenda. This isn’t possible in all contexts, but my current employer has a meeting-heavy culture and if I didn’t reject a lot of meetings, I would have little time for anything else. This doesn’t make me very popular, but I try to be kind when declining. Staying focused allows my team and me to deliver.

每天总是有足够的非开发任务来完成。确定哪些会议和任务是可选的需要时间和一些微妙的实验。我通常会在项目开始时参加所有会议并完成所有任务，当我感觉到那些没有增加价值的任务时，我开始逐个拒绝它们并观察是否有任何后果。如果我错误地判断了重要性，我会说我忽略了会议或任务，而没有对我的人际关系产生实质性影响。

There are always enough non-development tasks to fill every single day. Determining which meetings and tasks are optional takes time and a bit of delicate experimentation. I usually attend all meetings and follow through on all tasks at the start of a project and as I get a feel for those that are not adding value, I start to decline them one at a time and watch to see if there are any consequences. If I misjudge the importance, I say I overlooked the meeting or task without substantial impact to my relationships.

Jason 的关键问题：从开发人员过渡到 Tech Lead 时，对您来说最艰难的变化是什么？

Jason’s key question: What was the hardest change for you when transitioned from developer to Tech Lead?

在成为 Tech Lead 之前，我曾经是团队中最强大的技术贡献者之一。一旦我承担起领导职责，我就不再参与所有团队对话，也无法参与每个功能的实施细节。团队经常指望我帮助仲裁和打破有争议的僵局。我努力放弃参与每个功能的实施并推动特定的实施方法。如果我继续直言不讳，我就会损害仲裁和抢七的能力。

I was used to being one of the strongest technical contributors on teams prior to becoming a Tech Lead. Once I took on leadership responsibilities, I was no longer present for all team conversations nor able to be involved in the implementation details of every feature. The team often looked to me to help arbitrate and break contentious deadlocks. I struggled to let go of being involved in the implementation of every feature and driving particular implementation approaches. Had I continued to be outspoken, I would have compromised my ability to arbitrate and tie-break.

杰森的背景故事

Jason’s background story

Jason 首先将自己视为一名软件开发人员，尽管他在过去六年中一直领导着团队。他的职业生涯主要集中在银行、保险、公用事业和零售等业务领域的大规模、高可用性系统。

Jason considers himself first as a software developer, even though he has been leading teams for the past six years. His career has focused mostly on high-scale, high-availability systems in business domains such as banking, insurance, utilities and retail.

促进，然后领导——丹·阿贝尔

Facilitating, then Leading – Dan Abel

Tech Lead 应该关注什么？为什么？

What should a Tech Lead focus on and why?

人可能是协调和激励的最大挑战，但也是解决任何问题的最强大力量。了解你的团队并让他们了解你可以让你作为领导者、促进者和教练来引导团队采取强有力的行动。

People can be the biggest challenge to co-ordinate and inspire, but are the most powerful force to throw at any problem. To know your team and for them to know you allows you to work as a leader, a facilitator, and coach to guide the group to powerful actions.

我的指导原则是在他们不能的地方领导，在他们能的地方提供便利。这意味着在他们可以发光的地方让开，在他们周围建立足够的结构以确保他们得到支持。并在团队需要强有力的指导以应对挑战的前线进行领导。

My guiding rule is to lead where they cannot and to facilitate where they can. That means getting out of their way where they can shine, putting just enough structure around them up to ensure they are supported. And leading from the front where the team needs a strong guide to get on top of a challenge.

在领导力方面，我发现寻找机会帮助团队成长至关重要，这样我就可以自由地促进我曾经领导的事情。为此，我需要能够公平地观察和判断；展望未来，以同等的方式倾听和指导。我发现通过这种方式，您不必从一支优秀的团队开始，您可以建立一个。

When it comes to leadership, I’ve found it essential to find opportunities to help the team grow so that I have the freedom to just facilitate things I was once leading. To do that I need to be able to observe and judge fairly; looking to the future, listening and directing in equal measure. I’ve found that in that way you don’t have to start with a great team, you can build one.

如果你想要一个关于技术发现的观点，那就是决定什么看起来不错，然后逐步朝着那个方向努力，测量和评估，如果我们发现我们错了，愿意并准备好撕掉其中的一些。作为领导者意味着尽我所能管理风险和最后的责任时刻。我发现这很难，但我尝试通过 Plan Do Measure Adjust 周期来工作：适可而止，及时准备。

If you want a point about technical discovery, it’s about deciding what might look good and then incrementally working towards that, measuring and assessing, being willing and ready to rip some of it up if we find out we were wrong. Being a leader means managing the risks and last responsible moments to the best of my ability. I find it hard, but I try to work through Plan Do Measure Adjust cycles: just enough, ready in time.

作为 Tech Lead，您遇到的最大挑战是什么？

What has been your biggest challenge as a Tech Lead?

我对甘特图和深入的项目计划过敏，尽管我喜欢与优秀的项目或项目经理合作。在我职业生涯的早期，在我第二次担任 Tech Lead 期间，项目经理要求我根据我们所知道的情况提出一些粗略的估计。他想制定一个计划，在会议期间进行讨论。客户拿着这张甘特图，简单地按照计划推进，而没有根据我们了解到的新信息对其进行修改。客户对调整计划不感兴趣，即使在谈话中强调了所涉及的风险之后也是如此。最后，我和一位主管谈过，并在向他展示了其中的风险后，得到了他对改变我们工作方式的支持。

I’m allergic to Gantt charts and in-depth project plans, though I love working in partnership with a great project or programme manager. Early on in my career, during the second time I was a Tech Lead, the Project Manager asked me to come up with some rough estimates based on what we knew. He wanted to have a plan to talk through during a meeting. The client took hold of this Gantt chart, simply moving along the plan without revising it based on new information we had learned. The client wasn’t interested in adjusting the plan, even after conversations highlighting the risks involved. In the end, I talked to a director and gained his support to change our working style after showing him the risk involved.

现在我可能会以不同的方式解决问题，但我仍然会攻击根本原因。如果我们知道会阻止成功交付的事情，我不能袖手旁观。我们应该根据我们所知道的采取行动，即使它涉及坏消息和艰难的对话。

Now I might solve the problem differently, but I would still attack the root cause. I cannot sit back and do nothing if we know about something that will prevent a successful delivery. We should act on what we know, even if it involves bad news and difficult conversations.

几年后，我不得不亲自传达坏消息。我继承了一个不符合所有客户期望的项目。解决问题是我的工作。我创建了一个表格，突出显示了客户期望的功能以及我们在与客户的对话中使用这些功能之前的位置。不谈论这个问题会使事情变得更糟。必须处理坏消息，并制定下一步的计划。

A few years later I had to deliver bad news myself. I inherited a project that didn’t meet all client expectations. It was my job to solve the problem. I created a table, highlighting the features the client expected and where we were before using that in the conversation with the client. Not talking about the issue would have made things worse. Bad news has to be dealt with and a plan made over what to do next.

有什么时间管理技巧吗？

Any time-management tips?

生活往往会给我带来挑战，这些挑战总是比我准备好接受的挑战稍微大一点——或者也许我的眼睛比我的肚子大？结果是，当出现问题时，我可以真正集中注意力，但当事情照常进行时，众所周知，我很难知道下一步该做什么并完成所有重要的事情。

Life tends to throw me challenges that are always slightly bigger than I’m ready for Ð or perhaps my eyes are bigger than my belly? The result is that when there is a problem I can be really focused, but when it is business as usual, I have been known to struggle to know what to do next and get everything important done.

几年前，我阅读了 Rands 关于如何做我认为紧急和重要的事情的建议，这对我的工作方式产生了重大影响。紧急的是你需要完成的事情：也许人们正在要求它；也许你已经决定它需要发生。重要的是那些意味着如果你忽视它你就不会做你的工作，但没有人要求你做; 这些东西不是里程碑，但它是你一天和一周的流程，你与团队成员的聊天，一定要结对，故事墙上发生了什么，你的团队快乐和满意吗？

Some years ago I read the advice of Rands’ on how to do what I see as the urgent and the important, which had a big effect on how I worked. The Urgent is the stuff that you need to get done: perhaps people are asking for it; perhaps you have decided it needs to happen. The Important is the stuff that means you wouldn’t be doing your job if you ignored it, but no one is asking you to do; this stuff isn’t milestones, but it is the flow of your day and your week, your chats to your team members, being sure to pair, what’s going on the story wall, are your team happy and satisfied?

虽然我没有逐字逐句地遵循他的流程，但我使用索引卡作为我的待办事项列表；Rands 的 Daily Scrub 帮助我处理了更多我可以做的工作，细流列表帮助我将注意力集中在丰富的对话区域，这些对话似乎抓住了我不知道的事情。将这种情况与简短、更正式的会议相结合，可以帮助我凭直觉了解正在发生的事情以及可能需要进入我的待办事项平台的内容。

Though I don’t follow his processes verbatim, I use index cards for my to-do list; Rands’ Daily Scrub helped me deal with more work that I could do, and the trickle list helped me focus past that into the zone of rich conversations that seem to catch things I didn’t know about. A mixture of this, and short, more formal meetings helps me to intuit what is going on and what might need to get on to my to-do deck.

您如何在编写代码和处理其他问题之间取得适当的平衡？

How do you strike the right balance between writing code and dealing with other issues?

最近我在这方面不是很擅长，但我很幸运，因为我经常被优秀的开发人员包围，他们让我进进出出。

I’ve not been very good at this recently, but I’m fortunate as I’m often surrounded by good developers who let me drop in and out.

很大程度上取决于团队的规模和组成：当我在一个较小的团队中时，很明显我应该花时间编写代码；在较大的团队中，我喜欢抽出一些核心编码时间的想法，这样我就可以专注于我工作的那一部分。当我参与多团队交付时，我会花有限的编码时间在我知道存在痛苦或挑战的领域进行配对，并且我想为工作和代码做好准备成功，让我有机会亲身了解该地区可能潜伏的惊喜和压力。

A lot depends on the size and composition of the team: when I’ve been on a smaller team, it’s obvious that I should be spending my time coding; on larger teams, I like the idea of blocking out some core coding hours where I can focus on that part of my job. When I’ve been involved in multi-team deliveries, I’ve made a point of spending my limited coding time in pairing on areas where I know there has been pain or a challenge and I want to set the work and the code up for success, giving me a chance to understand the surprises and pressures that might lurk in the area first hand.

我不想失误，所以今年我想把事情混在一起，做一些让我有更多面向代码的角色的项目。

I don’t want to slip, so this year I’m looking to mix things up a bit and work on projects that allow me to have a more code-facing role.

Dan 的关键问题：Tech Lead 角色何时停止，其他角色何时开始？

Dan’s key question: When does the Tech Lead role stop and other roles begin?

Tech Lead 在紧急任务和重要任务之间，以及在执行和展望之间找到平衡。当 Tech Lead 过多地关注一个方面时，我看到他们选择退出这个角色。例如，如果我一直在开会，或者我一直专注于解决一个深层次的技术问题，那么我的团队就缺少一名 Tech Lead。

A Tech Lead finds balance between urgent and important tasks, and between doing and looking forward. When a Tech Lead focuses on one aspect too much, I see them opting out of the role. For example, if I am in meetings all the time, or I am permanently focused on solving a deep technical problem, then my team is missing a Tech Lead.

丹的背景故事

Dan’s background story

Dan 从小就开始探索计算机可以做什么，并在舞蹈和大量苹果酒的帮助下，通过学习 C 编程语言的计算机和大学里的人来跟进。在 18 年的时间里，他见过各种类型的环境，从小型初创企业到大型 C++ 产品公司。

Dan started to explore what computers can do at an early age and followed this up by studying both computers in the C programming language and people at college, with the help of dancing and lots of cider. In 18 years, he has seen environments of all types from small start-ups to a large C++ product company.

他曾多次领导团队，现在认识到什么是重要的：依靠强大的目标、实现目标的方法以及与愿意学习的人一起工作。

He has lead teams on several occasions and now recognises what is important: relying on a strong goal, the means to get there and working with people willing to learn.

帮助团队——亚当·埃斯特林

Helping the Team – Adam Esterline

Tech Lead 应该关注什么？为什么？

What should a Tech Lead focus on and why?

我认为 Tech Lead 能做的最重要的事情就是帮助他们的团队弄清楚哪些工作他们不会去做。很多事情可以占用一个团队，例如重构、学习新技术、添加新功能和修复错误。大多数时候，我们想做所有这些事情，但我们必须学会如何拒绝。说不可以有多种形式。例如，说“我们已经有了”，或者问“这是现在最重要的事情吗？”。

I think the most important thing a Tech Lead can do is to help their team figure out what work they are not going to do. Lots of things can occupy a team, such as refactoring, learning new technologies, adding new features, and fixing bugs. Most of the time, we want to do all those things, but we have to learn how to say no. Saying no can come in many forms. For example, saying, “We already have it,” or asking, “Is it the most important thing now?”.

我最大的担心可能是确保团队感觉自己是成功的。写代码很难，很容易倦怠。我努力确保团队定期从他们的工作中受益。

My biggest worry is probably making sure the team feels like it is successful. Writing code is hard and it is easy to burn out. I try to make sure that the teams are seeing benefits from their work on a regular basis.

作为 Tech Lead，您遇到的最大挑战是什么？

What has been your biggest challenge as a Tech Lead?

我想到了两个真正的挑战。当团队正在处理的代码进入错误状态时，第一个问题出现了。我们在定期交付代码时遇到了麻烦。作为一个团队，我们决定我们需要停止交付功能并处理导致问题的代码。这不是一个受我们所有利益相关者欢迎的决定。我们起草了一份相对较短的需要解决的问题清单，并在接下来的三个月内专注于解决这些问题，这样我们就可以回到稳定状态并重新开始交付功能。

Two real challenges come to mind. The first one arose when the code the team was working on had got into a bad state. We were having trouble delivering code on a regular basis. As a team, we decided we needed to stop delivering features and work on the code that caused problems. This was not a popular decision with all our stakeholders. We drew up a relatively short list of problems that needed to be addressed and we focused on solving them over the following three months so that we could then get back into a stable state and start delivering features again.

我面临的第二个挑战是决定转向持续部署；这是一个艰难的团队情况，真正得到了回报。部署每次提交时都有很多恐惧和不确定性。人们在问诸如“QA 如何适应这个模型？”之类的问题。和“我们真的可以信任开发人员承担那么多责任吗？”。我们花了很多时间讨论这些问题中的每一个。我们花了相当多的时间编写一个“安全网”，使我们能够安全地部署代码。我们还花时间在系统中引入故障，以查看我们的安全网的性能。最后，我们构建了一个可以快速响应客户需求和问题的系统。

The second challenge I had was deciding to move to continuous deployment; this was a tough team situation that really paid off. There was a lot of fear and uncertainty when deploying every commit. People were asking questions such as, “How does QA fit into this model?” and “Can we really trust developers with that much responsibility?”. We spent a lot of time discussing each of these issues. We spent considerable time writing a “safety net” that would allow us to deploy code safely. We also spent time introducing failures into the system to see how our safety net performed. In the end, we built a system that can react quickly to customer needs and issues.

有什么时间管理技巧吗？

Any time-management tips?

我每天早上 8 点到下午 1 点在我的日历中划出时间，那时候我不会接受会议。我利用这段时间编写代码并与我的团队一起工作。我早上和团队一起编码，下午处理问题。如果我不在日历中安排时间，我最终会把几乎所有时间都花在处理问题上。

I block out time in my calendar from 8am to 1pm every day, when I will not accept meetings. I use that time to code and work with my team. Where I spend my mornings coding with the team, I use the afternoons dealing with issues. If I do not block off time in my calendar, I would end up spending almost all my time working on issues.

我还强调只在早上或深夜回复电子邮件。我试着只在那个时候检查电子邮件。

I also make it a point to only answer email first thing in the morning or late at night. I try to check emails only at that time.

亚当的背景故事

Adam’s background story

自 1999 年以来，Adam 使用了多种编程语言，并花了几年时间为位于圣路易斯的华盛顿大学开设培训课程。自 2003 年以来，Adam 一直领导着从涉及硬件的项目到高流量网站的各个方面的团队。

Adam has worked with a wide range of programming languages since 1999 and has spent several years running training classes for Washington University in St. Louis. Adam has lead teams since 2003 in everything from projects involving hardware to high-traffic websites.

向内和向外——雷切尔·莱科克

Inwards and Outwards – Rachel Laycock

Tech Lead 应该关注什么？为什么？

What should a Tech Lead focus on and why?

我认为 Tech Lead 采取两种立场，向内看和向外看。

I think the Tech Lead takes two stances, looking both inwards and outwards.

对内来说，最重要的是团队，以及团队的动力。我关注整个团队的动态，而不仅仅是开发人员。我观察开发人员如何与团队中的其他角色（如分析师、测试人员和项目经理）互动。我考虑人们是否在学习，或者观察人们是否跟上，如果没有，考虑他们需要什么支持。我找出一个人想把他们的成长重点放在什么地方，看看人们是否愿意承担任务、支持想法和成长。在许多方面，我以与项目经理相同的方式保护团队。我尽量避免技术团队在有关架构或未来工作构想的会议上花费太多时间，这样他们就可以专注于确定当前工作的优先级。

Inwardly, the most important thing is the team, and the dynamics of the team. I watch for the dynamics of entire team, not just the developers. I watch how the developers interact with other roles in the team such as analysts, testers, and the project manager. I think about whether people are learning, or watch if people are keeping up and, if not, consider what support they need. I find out where a person wants to focus their growth and see if people feel comfortable taking ownership of tasks, championing ideas, and growing. In many ways, I protect the team in the same way a project manager might. I try to shield the technical team from spending too much time in meetings about architecture or ideation of future work, so they can focus on prioritising work in the present.

从表面上看，我经常充当技术团队和业务之间的管道。我考虑我们是否满足了利益相关者的需求，以及我们的解决方案是否以最佳方式解决了问题。我问自己，“是否有合适的人在合适的时间参与进来以做出最佳决策？” 我不断退后一步，从大局着眼，检查项目是否朝着正确的方向前进，并与未来的发布保持一致。我还是项目经理和分析师的顾问，以促进做出正确的决策，为分析阶段增加急需的技术视角。

Outwardly, I often act as the conduit between the technical team and the business. I consider whether we are meeting stakeholder needs, and whether our solution answers the problem in the best way possible. I ask myself, “Are the right people involved at the right time to make the best possible decisions?” I constantly step back to look at the bigger picture to check the project is heading in the right direction and aligns with future releases. I am also an adviser to project managers and analysts to facilitate good decisions, adding a much-needed technical perspective to the analysis phase.

作为 Tech Lead，您遇到的最大挑战是什么？

What has been your biggest challenge as a Tech Lead?

授权是我仍在努力解决的问题，所以我将举例说明这一点，但在利益相关者管理和管理期望方面存在许多挑战，这也是很难吸取的教训。

Delegation is something I still struggle with, so I’ll exemplify this, but there have been many challenges around stakeholder management and managing expectations, which have been difficult lessons to learn as well.

我在一家大型金融公司担任技术首席架构师；我有另一位来自 ThoughtWorks 的顾问（有时）和一个客户端开发人员团队。此外，我需要管理执行干系人及其不断的需求和期望。我没有通常的 BA、PM 等结构，所以我有很多空白需要填补。这是我真正与委派斗争的地方。一开始我处理不好；我只是让人们零碎地工作，这意味着开发人员总是不得不问下一步该做什么，就在我太忙的时候，我想不出给他们什么，或者，至少，给他们感觉很舒服。

I was working as a Tech Lead Architect role at a large financial company; I had another consultant from ThoughtWorks with me (some of the time), and a team of client developers. In addition, I needed to manage the executive stakeholders and their constant demands and expectations. I didn’t have the usual constructs of BA, PM etc, so I had a lot of gaps to fill. This is where I really struggled with delegation. I didn’t handle it well at first; I just gave people work to do piecemeal and this meant that the developers always had to ask what to do next, just when I was so busy I couldn’t think what to give them, or, at least, felt comfortable giving them.

最终，我意识到我会工作到死，除非我放弃一些东西，让他们自己工作，并学习如何根据我提供给他们的信息来管理和优先处理他们的工作。这很难，但我停下来询问每个开发人员他们真正想学习和从事的工作。一位开发人员想要培养更好的咨询技能，所以我让他主持会议并在我的支持下向客户展示。然后我会向他反馈进展顺利的细节以及他们可以改进的地方。我很难放手，但这确实改变了团队的态度，我不会经常被问到下一步该做什么。

Eventually, I realised I would work myself to death unless I let some stuff go and let them own work and learn how to manage and prioritise their work based on information I gave them. It was hard, but I stopped to ask each of the developers what they actually wanted to learn and work on. One developer wanted to develop better consulting skills, so I let him run meetings and present to the client with my support. I would then give him feedback on specifics of what went well and what they could improve. It was hard for me to let stuff go, but it did change the attitude of the team and I wasn’t constantly being asked what to do next.

当您知道如何完成一项任务而另一个人仍在学习时，委派尤其困难。你知道他们可能没有你做的那么好，但他们需要犯错误才能学习。好处是你不再是什么都做！

Delegation is especially hard when you know how to do a task and the other person is still learning. You know they may not do the task as well as you could, but they need to make mistakes in order to learn. The advantage is that you are no longer doing everything!

有什么时间管理技巧吗？

Any time-management tips?

这与授权有关：这是我仍在努力的事情！我发现将事物分解为高级概念，然后对它们进行优先排序，现在对我很管用。因此，例如，我首先决定我需要做什么，然后确定优先级；考虑到我的日历上经常满是会议，我必须对自己能取得的成就现实一点。总会有无法完成的任务，所以我会考虑可以委托给谁。我试图根据人们想要成长的领域做出决定，但有时我只需要让他们做他们可能不关心的任务。

This ties in with delegation: it is something I am still working on! I am discovering that breaking things down into high-level concepts and then prioritising them is working for me right now. So, for example, I start by deciding what I need to do and then define priorities; I have to be realistic with myself about what I can achieve, given that my calendar is often full of meetings. There will always be tasks I cannot get done, so then I think about who I can delegate those to. I try to base my decision on the areas where people want to grow, but sometimes I simply have to ask them to do tasks they may not care for.

总而言之，我将事情分解为三到四个高级任务，确定优先级，然后委派。我指的是“你的大脑在工作”（大卫·洛克），它解释了人脑很难确定优先次序和做出决策，所以你应该在你处于最佳状态时去做，并通过打破自我来让自己更轻松它分为三四件事。

To summarise, I break things down into three or four high-level tasks, prioritise, then delegate. I refer to “Your Brain at Work” (David Rock), which explains that prioritisation and decision-making is hard for the human brain to do, so you should do it when you are at your best and make it easier on yourself by breaking it into three or four things.

它并不总是有效；我经常尝试自己做这一切，但我一直在为自己和团队努力。

It doesn’t always work; I often try to do it all myself, but I am constantly working on myself as well as the team.

您如何在编写代码和处理其他问题之间取得适当的平衡？

How do you strike the right balance between writing code and dealing with other issues?

很难。编码是一项非常专注的活动，我可能会沉浸在一个故事中，而专注于下一个要编写的测试，例如，但是作为技术主管，您需要密切关注架构、代码的演变，是吗实现更广泛的目标？该解决方案能否与管道中的事物一起工作 - 只有您可能知道的事物，因为您在会议中讨论下一个版本。您还需要注意团队动态。合适的人是否相互配对？人在成长吗？就个人而言，我发现如果我加入和退出故事而不是拥有它们会更容易。这样我就不会陷入太多细节，我可以提醒自己，对于我的团队来说，我更像是一名教练，而不是一名编码员。

It is hard. Coding is a very focused activity and I can lose myself in a story and become focused on the next test to write, for example, but as a Tech Lead you need to keep an eye on the architecture, the evolution of the code, does it meet the broader goals? Will the solution work with things that are in the pipeline - things that only you may know about because you were in the meeting to talk about the next release. You also need to pay attention to team dynamics. Are the right people pairing with each other? Are people growing? Personally, I find it easier if I drop in and out of stories rather than owning them. Then I don’t get too caught up in too much detail and I can remind myself that I am more a coach than a coder for my team.

Rachel 的第一个关键问题：“你将如何指导开发人员成为 Tech Lead？”

Rachel’s first key question: “How would you coach a developer into being a Tech Lead?”

最重要的一点是，他们明白自己不再负责成为团队中最好的编码员，而是负责确保其他人都尽力而为。帮助他们了解所涉及的风险，并帮助他们找到鼓励其他人做出贡献的方法，尤其是当他们领导的团队经验不足时。向他们展示在团队中分散设计责任的方法。鼓励他们使用苏格拉底式的提问方法，而不是让他们首先向团队展示他们的想法。教他们各种提问方式，帮助团队自己想出答案。问题是，“那呢？” 经常有帮助。

The most important point is that they understand that they are no longer responsible for being the best coder on the team, but for making sure everyone else does their best. Help them to see the risks involved and help them find ways of encouraging everyone else to contribute, particularly if they are leading an inexperienced team. Show them ways to spread responsibility for designs in the team. Encourage them to use a Socratic questioning method instead of letting them first present their idea to a team. Teach them various questioning styles to help the team come up with the answers themselves. The question, “What about?” often helps.

教他们认识人们所拥有的技能以及这些技能最适合应用的地方。帮助他们在整个团队共享技能和“高效”地进行软件交付之间找到平衡点。帮助开发人员培养倾听和影响技能，因为他们将与业务部门以及潜在的其他技术团队、架构师或其他技术主管进行更多互动。最后，为开发人员确定一个支持网络，并说服他们不要默默忍受，并在需要时寻求帮助。帮助他们找到经验丰富的良师益友，或担任不同角色的人，以获得想法的反馈，并在困难时期提供支持或指导。

Teach them to recognise the skills people have and where they might be best applied. Help them to find a balance between sharing skills across the team and being “efficient” with software delivery. Help the developer build listening and influencing skills, as they will have more interaction with the business and potentially other technical teams, architects or other Tech Leads. Finally, identify a support network for the developer and persuade them to not suffer in silence and to ask for help when needed. Help them find a good mentor with more experience, or someone who works in a different role to get feedback on ideas, and to provide support or guidance through trying times.

Rachel 的第二个关键问题：“当你不经常编写代码时，你如何保持技术和相关性？” 接受你不太可能保持团队中最好的编码员的事实，这纯粹是因为你将减少编码。专注于你需要了解或学习的上下文。你仍然必须表现出对技术的热情，因为你可能会发现自己在自己的时间里学到了更多。

Rachel’s second key question: “How do you remain technical and relevant when you don’t get to code that often?” Accept that you are unlikely to remain the best coder on the team, purely because you will be coding less. Focus on what you need to know or learn for the context. You must still demonstrate passion about being technical because you may find yourself learning more in your own time.

鼓励团队组织“棕色包”会议，让您和其他团队成员了解团队正在学习的内容。您将更多地依赖阅读代码来了解正在发生的事情，并尽可能多地与开发人员结对编程。我的目标是让这占我 50% 的时间。

Encourage the team to organise “Brown bag” sessions to keep you and other team members abreast of what the team is learning. You will rely more on reading the code to understand what is going on and pair-program with developers as much as possible. I aim to make this about 50 per cent of my time.

雷切尔的背景故事

Rachel’s background story

Rachel 是一位拥有十年软件开发经验的资深人士，过去领导过六个团队。自从她第一次担任 Tech Lead 的外衣并发现人的问题比技术问题更难解决时，她就对这个角色很感兴趣。她曾经认为团队中最有技术含量的人应该领导团队，但她意识到深厚的技术知识并不能帮助 Tech Lead 解决人们的问题。Rachel 还特别热衷于如何吸引和留住更多女性从事技术工作，尤其是担任技术专家职位。她还希望看到女性更多地扮演技术主管的角色。

Rachel is a software development veteran of ten years, having led six teams in the past. The role has interested her since she first wore the Tech Lead mantle and discovered people problems are much more difficult to solve than technical ones. She used to think the most technical person on the team should lead, but realised deep technical knowledge does not aid the Tech Lead in solving people problems. Rachel is also particularly passionate about how to get and keep more women in technology, particularly in technologist roles. She would also like to see women play the Tech Lead role more often.

软技能——乔恩·皮瑟

Soft Skills – Jon Pither

Tech Lead 应该关注什么？为什么？

What should a Tech Lead focus on and why?

在你的团队中找到最优秀的人。这是很明显的一点，但最优秀的人往往会为你解决大部分问题。例如，必须进行教育和直线管理的问题很快就会转化为您应该如何最好地委派的问题。

Get the best people in your team. It is such an obvious point, but the best people tend to solve most problems for you. For example, problems of having to educate and line manage can quickly evaporate into questions of how you should best delegate.

我喜欢自组织团队。同时，Tech Lead 需要带来正能量。Tech Lead 需要挑起事端、提出问题并促进会议，以便每个人都能有公平的发言权。为此，我借鉴了老式的会议管理技巧，专注于当天最重要的问题，并寻求就结果达成一致。尽管有些人认为成熟的团队不需要促进，但根据我的经验，这很少是真的，尤其是当问题很复杂或定义不明确时。这可能会让人筋疲力尽，但领导者必须准备好在情感上和智力上付出很多。

I love self-organising teams. At the same time, a Tech Lead needs to bring positive energy. A Tech Lead needs to stir things up, to ask questions, and to facilitate meetings so that everyone can have a fair say. I do this by drawing upon good old-fashioned meeting management techniques, focusing on the biggest issue for the day, and seeking agreement on outcomes. Although some people think well-established teams don’t require facilitation, in my experience this is rarely true, especially when the problem is complex or ill defined. It can be exhausting, but a lead must be prepared to give a lot of themselves, emotionally and intellectually.

Tech Leads 应该专注于培养软技能。优秀的 Tech Lead 会利用这些技能来寻求团队成员之间的平衡，突破可能的界限，并注意到那些乐于待在舒适区内的人。我应该指出，作为 Tech Lead，你的工作不是自动解决或增加摩擦。只要不阻碍团队前进，分歧就是健康的。

Tech Leads should focus on developing soft skills. A good Tech Lead draws upon these skills to seek balance between team members, to push boundaries of what is possible, and to notice those happy to stay within their comfort zone. I should point out that your job as Tech Lead is not to automatically solve or increase friction. Disagreements are healthy as long as it does not block the team from moving forward.

最后，技术主管应该准备好为了更大的利益而让位，我的意思是在三个要素之间找到适当的平衡：

Lastly, a Tech Lead should be prepared to step aside for the greater good, by which I mean finding the right balance between three elements:

• 雇主或企业：买单的人最终代表更大的利益。
• The employers or the business: those who foot the bill ultimately represent the greater good.
• 项目：团队来来去去，随着时间的推移而变化。我们建立的系统比我们活得更久。
• The project: teams come, go, and change over time. The systems we build outlive us.
• 团队：我首先将团队视为个体，然后将其视为围绕着让人们开心的事物的集体。我喜欢引用我的一位前同事 (Häken Räberg) 的话：“我们没有得到报酬来享受工作，但这并没有什么坏处。”
• The team: I consider the team as individuals first, and as a collective around what would make people happy. I like to quote of a former colleague of mine (Häken Räberg): “We are not paid to enjoy ourselves at work, but it doesn’t hurt.”

担任此角色的任何人都应该为团队的利益而工作。当一个团队正在进行彻底的转型时，例如，语言和支持技术的变化，Tech Lead 的角色可能会更好地转移或共享。

Whoever works in this role should be working in the interests of the team. When a team is undertaking a radical transformation, for example, a change of language and supporting technologies, the Tech Lead role may better be transitioned or shared.

作为 Tech Lead，您遇到的最大挑战是什么？

What has been your biggest challenge as a Tech Lead?

我曾经辞去 Tech Lead 的角色，因为我觉得我必须把所有的精力都放在编码上。我让团队陷入近乎无政府状态以促进技术转变，并觉得其他人可以更好地恢复某些流程，清理我的烂摊子。我也非常致力于确保技术转变的成功，所以这是我需要集中精力的地方。这让 Tech Lead 的其他职责所剩时间所剩无几，而这些职责可能会在许多方面耗费心力。

I once stepped down from the role of Tech Lead as I felt I had to devote all my energy to coding. I brought the team into a state of near anarchy to facilitate a technology shift and felt someone else could do a better job of restoring some process, cleaning up my mess. I also felt extremely dedicated to ensuring the technology shift succeeded, so this was where I needed to focus my energy. This left little time for other Tech Lead responsibilities that can be emotionally draining on many fronts.

由于我试图成为变革的推动者，因此我需要其他人来担任镇定剂的角色；能够更好地将团队成员的观点与对立策略结合起来的人，我就是其中之一。我不能扮演这两个角色。我找到了一位继任者，我相信他具备必要的软技能来促进激烈的讨论，并且能够欣赏大局。

Since I was trying to be an agent for change, I needed someone else to take on the role of calming agent; someone who could better integrate the views of team members with opposing strategies, of which I was one. I could not play both roles. I found a successor who, I believed, had the necessary soft skills to facilitate heated discussions and had the appreciation of the bigger picture.

我经常遇到的另一个挑战是处理一个变得陈旧的团队。一个团队需要新鲜血液；它需要新的创造力来源。为此，我寻找了不起的毕业生来提升团队，并在我的网络中寻找我非常敬佩的人，我认为他们应该有所作为并激发人们的兴趣。

Another challenge I have often encountered is dealing with a team getting stale. A team needs new blood; it needs new sources of creativity. To do this, I sought out amazing graduates to lift a team, as well as scouring my network for people I highly admire, whom I think should make a difference and excite people.

我发现很难与团队中倾向于保守或消极观点的开发人员打交道。我希望团队中的每个人都快乐和兴奋，但这也许是我自己的失败之一。您需要团队中具有不同观点和不同优势的不同人员。仅仅因为我是一名技术主管，我不应该因为人们对团队所做的工作不感兴趣而失眠。

I find it hard to deal with developers in my team who lean towards a conservative or a negative viewpoint. I want everyone in my team to be happy and excited, but perhaps this is one of my own failings. You need different people on a team with different viewpoints and different strengths. Just because I am a Tech Lead I should not lose sleep over people not being thrilled by work the team is doing.

有什么时间管理技巧吗？

Any time-management tips?

待办事项清单是必不可少的。无聊的事情，比如使用日历帮助。Emacs 中的 Org 模式也很不错。

To-do lists are essential. Boring things like using a calendar help. Org mode in Emacs rocks too.

您如何在编写代码和处理其他问题之间取得适当的平衡？

How do you strike the right balance between writing code and dealing with other issues?

你不应该一直坚持做 Tech Lead 和写代码。如果你不能两者都做，那就不要：选择一个。我曾经在 Java 论坛的某处读到：“选择一件事并做好它，而不是两件事都做不好。”

You shouldn’t hang on to being a Tech Lead and writing code all the time. If you cannot do both, then don’t: pick one. I once read somewhere on a Java forum: “Pick one thing and do it well rather than suck at both.”

但我从授权中获得了巨大的成功和快乐。如果你有一个很棒的团队，请委派。在较小的区域设置“stream leads”或 Tech Leads。询问团队他们认为您如何最好地委派。回顾是必须的。醉酒的酒吧场景并没有什么坏处。

But I’ve had great success and joy from delegation. If you have a great team, delegate. Set up “stream leads” or Tech Leads over a smaller area. Ask the team how they feel you can best delegate. Retrospectives are a must. A boozy pub scene doesn’t hurt.

Jon 的第一个关键问题：我认为自己是一名优秀的 Tech Lead 吗？

Jon’s first key question: Do I consider myself a good Tech Lead?

对此我五味杂陈。我能带来正能量；我可以获得团队的信任，并愿意克服出现的任何障碍。另一方面，我与自己的自信恶魔作斗争，感觉不够好，无法领导一些了不起的人。这可能具有挑战性。当我觉得我的团队受到大型机构中可能不尊重我们所做工作的人的攻击时，我会感到压力。我是一个非常热情的人，有时我觉得我会从政治上更加精明而受益。

I have mixed feelings about this. I can bring good energy; I can gain a team’s trust and be willing to push whatever barrier presents itself. On the other hand, I struggle with my own demons of confidence, of not feeling good enough to lead some amazing people. It can be challenging. I can get stressed when I feel my team is under attack from people in large institutions that may not respect the work we do. I am a very passionate person, and sometimes I feel I would benefit from being more savvy at politics.

乔恩的第二个关键问题：我怎样才能提高自己？

Jon’s second key question: How can I improve myself?

每天打坐！尽量不要把工作看得太重，多享受团队内部的乐趣。我喜欢像非暴力沟通这样的沟通技巧，尽管很容易忘记这种做法。

Meditate every day! Try not to take the work too seriously and enjoy the playfulness inside teams more. I love communication techniques like Nonviolent communication, although it is too easy to forget such practices.

乔恩的背景故事

Jon’s background story

Jon 在 IT 领域工作了 12 年，在过去的四年里，他担任过三到四个团队的技术主管。他对使用开源软件和为开源软件做出贡献有着特别强烈的热情，并且最近对使用 Clojure 解决问题产生了浓厚的兴趣。

Jon has worked in IT for 12 years, where he has acted as the Tech Lead for three to four teams in the last four years. He has a particularly strong passion in using and contributing to open source software and has most recently found a passion for using Clojure to solve problems.

赋能人——伊莎贝拉·德根

Enabling People – Isabella Degen

Tech Lead 应该关注什么？为什么？

What should a Tech Lead focus on and why?

Tech Lead 应该使团队中的每个人都能尽可能地提高工作效率。他们应该让每个团队成员都觉得他们是朝着同一个目标努力的单一团队的一部分。他们确保开发人员真正理解需求并共同拥有代码库。我实现这一目标的一种方法是确保我不会首先提出我的想法，并鼓励其他人分享他们的想法。我尽量不告诉人们我会做什么，因为我发现这会阻碍人们提出自己的想法。我对此很谨慎，虽然这取决于团队，但我会推迟提出自己的想法，直到我更好地了解团队中的人员。

A Tech Lead should enable each person on the team to be as productive as they can be. They should make each team member feel they are part of a single team working towards the same goal. They ensure developers truly understand the requirements and co-own the codebase. One way I achieve this is by ensuring I do not present my ideas first, and by encouraging others to share their ideas. I try not to tell people what I would do, because I find this discourages people from presenting their own ideas. I am careful about that, and although it depends on the team, I delay presenting my own ideas until I better know the people on the team.

我尝试每天花半小时与团队中的开发人员一起提问，例如：

I try to spend half an hour every day with the developers on the team to ask questions such as:

• 代码库中存在哪些问题？
• What problems exist in the codebase?
• 你有什么新想法可以尝试吗？
• Do you have any new ideas to try?
• 我们在哪里花费最多的时间，我们能做些什么？
• Where are we spending the most time and what can we do about it?
• 你有什么想法吗？
• Is there anything on your mind?

我花了很多时间试图鼓励经验不足的开发人员分享他们的想法，因为即使他们可能并不总是有效，但他们经常会想出不同的方法。结合经验丰富的开发人员的经验，我们通常最终会得出一个可行的新解决方案。

I spend a lot of time trying to encourage less experienced developers to share their ideas, because even though they may not always work, they often come up with different approaches. Mixed with the experience of seasoned developers, we often end up with a new solution that will work.

有些想法需要很长时间，所以我还与开发人员合作，寻找我们可以逐步改进的方法，以帮助开发下一组功能。我发现这是获得利益相关者对技术改进支持的最佳方式。

Some ideas take a long time, so I also work with developers to find ways we can incrementally improve to help with the next set of functionality being developed. I find this is the best way for getting stakeholder support for technical improvements.

Tech Leads 还应该确保项目中的不同角色不会在他们自己的孤岛中工作，从而将工作扔到墙上。我试图阻止开发人员在不涉及其他角色的情况下接手工作，如果我注意到它，通常会按他们的方式发送业务分析师 (BA) 和质量分析师 (QA)。我发现有趣的是，BA 和 QA 通常是团队中的少数，从来没有涉及其他角色的问题。他们想谈谈。通常是开发人员，他们认为他们知道需要做什么，需要鼓励与其他角色的人一起工作。

Tech Leads should also ensure different roles on a project do not work in their own silos, throwing work over a wall. I try to prevent developers picking up work without involving other roles and, if I notice it, will often send the Business Analyst (BA) and Quality Analyst (QA) their way. What I find interesting is that BAs and QAs, who are normally the minority of the team, never have issues involving other roles. They want to talk. It is often developers, who think they know what needs to be done, who need the encouragement to work with people in other roles.

我尝试打破团队孤岛的另一种方式通常是在社交活动中。作为 Tech Lead，我经常花更多时间与项目经理或产品负责人的角色打交道。在团队午餐等社交场合，我尽量避免坐在这些人旁边，给其他人与他们互动的机会。

Another way I try to break silos across teams is often at social events. As a Tech Lead, I often spend more time with people in the roles of Project Manager or Product Owner. At social occasions such as a team lunch, I try to avoid sitting next to these people to give others an opportunity to interact with them.

Tech Lead 应该专注于生产路径。我喜欢通过设想上线日期、发布到生产环境，然后从那里开始逆向工作来开始设计和构建解决方案。我确定必须完成哪些工作，以及我们可能遇到和必须克服的障碍。

A Tech Lead should focus on the path to production. I like to start designing and architecting a solution by envisaging a go-live date, the release into production, and work backwards from there. I identify what work must be done, and the impediments we might encounter and must overcome.

技术主管与业务部门合作，就可以完成多少工作达成共识，从而帮助确定他们想做的事情的优先级。他们还通过将技术需求和术语翻译成更通用的语言来帮助非技术团队成员了解开发团队中发生的事情。

A Tech Lead works with the business to develop a shared understanding of how much work can be done, and therefore help prioritising what they want to do. They also help non-technical team members understand what is occurring in the development team by translating technical needs and terms into a more general language.

作为 Tech Lead，您遇到的最具挑战性的情况是什么？您是如何处理的？

What has been your most challenging situation as a Tech Lead and how did you handle it?

我作为 Tech Lead 的第一个项目是最具挑战性的情况，因为我没有经验，也不了解这个角色是做什么的。我发现很难让团队尊重我，事后看来，这并不奇怪，因为我完全误解了我必须让团队自由设计他们的工作。我应该一直扮演牧羊人的角色，照顾他们并引导他们朝着正确的方向松散地前进，而不是强制执行我所有的想法。

My first project as Tech Lead was the most challenging situation, because I did not have the experience and did not understand what the role was about. I found it difficult to get the team to respect me, which, in hindsight, is no surprise given that I totally misunderstood that I had to give the team the freedom to design their work. I should have been acting as a shepherd, looking after them and steering them loosely in the right direction, rather than enforcing all my ideas.

幸运的是，我和一位经验丰富的项目经理一起工作，我们每天花一个小时在一起讨论问题。这些讨论帮助我更多地了解我的角色。来自所有团队成员的反馈让我在下一轮和从那以后改变了我的方法。

Luckily, I was working with an experienced project manager and we spent an hour together every day to discuss problems. These discussions helped me understand more about my role. Feedback from all the team members was what made me change my approach the next time round and ever since.

有什么时间管理技巧吗？

Any time-management tips?

每天，在我们团队的站立会议之前，我都会尽量早点到，这样我就可以花 40 分钟完全安静地思考项目中发生的事情。我问自己这样的问题，“是否有任何气味或反模式出现？我们是否仍然遵循我们的愿景？人都上船了吗？”

Every day, before our team’s stand-up meeting, I try to arrive early so that I can spend 40 minutes in total quiet where I can ponder over what is going on in the project. I ask myself questions like, “Are there any smells or anti-patterns appearing? Do we still follow our vision? Is everyone on board?”

我让我的团队知道我在这段时间里在做什么，这样就不会占用我的时间。我认为重要的是要有远见的时间，而不仅仅是完成任务的时间。

I let my team know what I am doing during this time so the time is not taken from me. I think it is important to have time for visioning and not just time to work through tasks.

我确保我在一天中有固定的、不间断的大块时间（例如每天整个下午，或每周整整两天）没有任何会议，这样我就可以编写代码并与其他开发人员结对编程。

I ensure I get solid, unbroken chunks of time throughout the day (such as all afternoon each day, or two full days a week) without any meetings so that I can write code and pair program with other developers.

我将尽可能多的责任（总是比你认为你应该承担的责任多一点）交给团队的其他成员。这节省了我的时间，而且成员通常发现拥有系统的整个部分（例如集成点）会更有成就感。

I give as much responsibility (always slightly more than you think you should) to other members of the team. This frees up my time, and the members often find it much more fulfilling to own whole parts of a system such as an integration point.

您如何在编写代码和处理其他问题之间取得适当的平衡？

How do you strike the right balance between writing code and dealing with other issues?

写代码是我最喜欢做的事情。然而，我经常将它降低优先级，转而解决一个我注意到会解除对更多团队成员的阻塞的问题。我觉得同时了解技术和业务方面的人最适合引导团队远离障碍。当团队确实因障碍而停止时，他们也往往更善于寻找解决方案。

Writing code is what I love doing most. However, quite often I deprioritise it in favour of resolving an issue that I notice would unblock more members of the team. I feel that people who understand both technical and business aspects are best placed to steer the team away from obstacles. They also tend to be better at finding solutions when the team does halt due to a block.

我尽量避免查看我的团队的签到。相反，我确保具有更多经验的开发人员对关键故事进行结对编程。如果我的团队成员中没有那种经验，那么我会在代码库中花费更多的时间。

I try to avoid reviewing my team’s check-ins. Instead, I ensure that the developers with more experience pair program on the critical stories. If I do not have a team member with that experience, then I spend much more time in the codebase.

我将自己视为代码库中的访客，而不是所有者。我利用代码库中的时间来检测代码和架构气味、反模式、可维护性问题，并与团队讨论这些问题。理想情况下，他们将负责解决这些问题。我还利用这段时间更好地了解不同开发人员的优势，强调他们何时提出好主意，并推动他们如何与更广泛的社区分享这些想法。

I see myself as a guest in the codebase and not as the owner. I use the time in the codebase to detect code and architectural smells, anti-patterns, maintainability issues, and discuss these with the team. Ideally they will take ownership to resolve those. I also use the time to better understand the strengths of different developers, highlighting when they come up with a great idea and nudging them on how they might share that with a wider community.

Isabella 的关键问题：如何让有不同意见的固执己见的开发人员更好地融入团队？

Isabella’s key question: How do I get opinionated developers with divergent opinions better integrated as a team?

我对此没有很好的答案。目前，我认为需要时间来理解他们为什么不喜欢与他人合作或不考虑他人的建议。

I do not have a good answer to this. At the moment, I would say it takes time to build an understanding of why they do not like working with other people or consider other people’s suggestions.

过去我和他们坐在一起，解释我的期望和原因。我让他们向我解释为什么他们有不同的方法。通常可以找到一些中间立场。但我很想听听其他人在这些情况下是怎么做的。

In the past I have sat with them and explained what I expected and why. I let them explain to me why they had a different approach. Normally there is some middle ground that can be found. But I would be interested to hear what other people do in these situations.

伊莎贝拉的背景故事

Isabella’s background story

Isabella 于 2006 年开始在 ThoughtWorks 工作，并于 2008 年开始了她的 Tech Lead 之旅。从那时起，她在超过八个不同的团队中担任过 Tech Lead 角色，主要使用 Java 和 .Net 技术。她拥有苏黎世联邦理工学院的电气工程和信息技术理学硕士学位。

Isabella started working for ThoughtWorks in 2006 and began her Tech Lead journey in 2008. Since then, she has played the Tech Lead role for over eight different teams, mostly using Java and .Net Technologies. She has a Masters of Science in Electrical Engineering and Information Technology from the ETH Zurich.

这与代码无关——Patric Fornasier

It’s Not About the Code – Patric Fornasier

Tech Lead 应该关注什么？为什么？

What should a Tech Lead focus on and why?

能够掌握技术是绝对必要的，但它本身不足以有效地交付软件。一个成功的 Tech Lead 应该关注的另外两个主要领域是人和流程。编写出色的代码没有多大意义，例如，如果您正在解决错误的业务问题，因为您与客户的沟通不够。或者，让一名开发人员处理故事以外的其他事情可能是有意义的，例如分析、技术任务、操作或测试，如果这能让团队更快的话。在这个角色中，你不断地做出这些成本/价值决策，并根据你希望团队关注的重点来确定优先级。

Being able to master technology is absolutely necessary, but not sufficient in itself to deliver software effectively. Two other main areas that a successful Tech Lead should focus on are people and process. There is not much point writing great code, for example, if you are solving the wrong business problem, because you did not communicate enough with your customers. Or, it might make sense to have one developer work on something else other than stories, such as analysis, tech tasks, operations, or testing if this makes the team go faster. In this role, you make these cost/value decisions continuously and prioritise according to what you want the team to focus on.

作为技术主管，我一次旋转许多盘子。我最关心的是弄清楚哪些板块需要继续旋转，哪些板块我可以让它们崩溃。

As a Tech Lead, I spin many plates at once. What occupies my thoughts the most is figuring out which plates need to keep spinning and which ones I can afford to let crash.

通常，我的每一天都忙于做出决策，在成本和价值之间取得平衡，以实现短期、中期和长期的最佳结果。例如，我需要非常了解我的团队，以便我可以决定谁最适合从事给定的任务。影响此决定的因素有很多，例如任务重要性、任务紧迫性、团队成员技能组合、经验和个人偏好。

Usually, my days are filled with making decisions to strike a balance between cost and value in order to achieve an optimal outcome - short, medium, and long term. For example, I need to know my team well so that I can decide who is most suitable to work on a given task. There is a number of factors that influence this decision, such as task importance, task urgency, team-member skill set, experience, and personal preferences.

作为 Tech Lead，您遇到的最大挑战是什么？

What has been your biggest challenge as a Tech Lead?

我认为最困难的事情之一是平衡短期目标和长期目标。出售短期收益很容易，但需要更多的经验、纪律和技巧才能放弃今天的速赢，以期在明天取得更好的成绩。我想到的一个例子是，当我正在从事的一个大型项目的首席技术官 (CTO) 要求我为我们当前的迭代增加额外的一天，因为他下周要召开一次重要的董事会会议，他想把通过展示比我们实际取得的更多进展，我们处于良好的状态。这在短期内是一个诱人的提议，但我知道它最终会适得其反。

I think one of the hardest things is balancing short-term against long-term goals. It is easy to sell a short-term gain, but it requires more experience, discipline and skill to forgo a quick win today in favour of being in a better place tomorrow. One example that springs to mind, is when the Chief Technical Officer (CTO) of a large project I was working on asked me to add an extra day to our current iteration, because he had an important board meeting the following week and wanted to put us in a good light by demonstrating more progress than we had actually made. It was a tempting proposition in the short term but I knew it would backfire eventually.

我坚持自己的立场需要一些勇气，但我解释说，如果他想假装进步，有更简单的方法可以做到。他放弃了自己的想法，向董事会提交了实际数据，结果很顺利，避免了对团队交付能力设定不切实际的期望。

It took some courage for me to stand my ground, but I explained that if he wanted to fake progress there are easier ways to do that. He abandoned his idea and presented actual data to the board, which went down well and avoided setting unrealistic expectations of what the team was capable of delivering.

有什么时间管理技巧吗？

Any time-management tips?

我努力让我的优先事项正确。一般来说，总是有比我可能做的更多的工作，所以它是关于决定什么是最重要的。我通常在早上花几分钟在一张纸上写下我的优先事项，我整天都带着它。时不时地，我会花几分钟时间查看列表或勾选。每当我在某件事上花费超过几分钟的时间时，我都会检查清单，看看我正在处理的任务是否真的是我应该处理的最重要的事情。如果不是，我要么立即停止，要么花一分钟时间重新确定优先级。这样一来，我总是充分意识到我正在把时间花在我认为最重要的事情上。

I try to get my priorities right. Generally, there’s always more work than I could possibly do, so it is about deciding what’s most important. I usually spend a few minutes in the morning writing down my priorities on a piece of paper, which I carry with me throughout the day. Every now and then, I take a couple of minutes to review the list or tick things off. Whenever I am spending more than a couple of minutes on something, I check the list to see if the task I am working on is actually the most important thing I should be working on. If it is not, I either stop immediately or take a minute to re-prioritise. That way, I am always fully aware that I am spending my time on what I decided was most important.

您如何在编写代码和处理其他问题之间取得适当的平衡？

How do you strike the right balance between writing code and dealing with other issues?

取得这种平衡很难。编写代码需要很长一段不间断的时间，对于 Tech Lead 来说，这些时间段变得越来越少。即便如此，我认为 Tech Lead 花时间在代码库上是必要的。技术负责人确保代码库保持健康。如果您不知道自己在说什么，我认为您无法领导开发团队。作为原则，我不会要求开发人员做我自己不会做的事情。这是让我保持诚实并让我欣赏我要求他人完成的工作的一种方式。

Striking this balance is hard. Writing code takes long blocks of uninterrupted time and for a Tech Lead, these blocks become rarer. Even so, I think it is necessary that a Tech Lead spends time on the code base. A Tech Lead ensures the code base remains healthy. I don’t think you can lead a team of developers if you do not know what you’re talking about. As a principle, I don’t ask a developer to do something that I would not do myself. It is a way to keep me honest and allows me to appreciate the work I ask others to do.

有几种方法可以帮助我应对干扰：

There are a few approaches to help me deal with distractions:

• 配对程序——当我分心时，我的搭档可以继续完成任务。当我回来时，我发现更容易回到流程中。
• Pair program - When I get distracted, my pair can continue working on the task. When I return, I find it easier to get back into the flow.
• 委派工作——当人们在处理关键部分时，我会坐下来与他们交谈。一旦我觉得他们不再需要我了，我就让他们继续我的生活。
• Delegate work - I sit down with people when they’re working on a crucial part. As soon as I feel they don’t need me any more, I let them go on without me.
• 寻找安静的时间——我试着每周花几个小时把自己锁在一个房间里，或者在家工作直到午餐时间。
• Find quiet time - I try to take a couple of hours every week to either lock myself into a room or work from home until lunchtime.

帕特里克的关键问题：你如何让你的技术工具保持锋利？

Patric’s key question: How do you keep your tech tools sharp?

我认为这真的有三个基本部分：网络、警觉性和学习。我非常依赖我的专业网络来过滤和展示新的想法、工具、技术等。同时，我会挑选我不熟悉的名字或术语。如果我拿起什么东西，我会花点时间将它放在上下文中并理解如何使用它。在这个阶段，我的学习是肤浅的，我只是在广度上进行优化，而不是在深度上进行优化，但它帮助我建立了一个资源目录，当我遇到特定问题时，我可以在以后的阶段回过头来。在那个阶段，我花更多的时间去深入学习。这与需要解决的特定问题相结合，使我能够快速有效地学习。

I think there are really three essential parts to this: networking, alertness and learning. I am relying heavily on my professional network to filter and surface new ideas, tools, techniques, etc. At the same time, I pick up names or terms I am not familiar with. If I pick something up, I spend a moment putting it in context and understanding how it could be used. At this stage, my learning is superficial and I am only optimising for breadth, not depth, but it helps me build up a catalogue of resources that I can come back to at a later stage when I am confronted with a specific problem. At that stage, I spend more time to learn in depth. This, in combination with having a specific problem to solve, allows me to learn quickly and effectively.

帕特里克的背景故事

Patric’s background story

Patric 在商业软件领域工作了 10 多年，在此之前曾在学术界工作过。尽管他喜欢编码，但他发现自己总是在寻求改进团队和流程，这自然使他成为了 Tech Lead。他认为软件中最困难的挑战是社会方面而不是技术方面。

Patric has worked in commercial software for over 10 years, having spent time before that in academia. Although he enjoys coding, he finds himself always looking to improve teams and processes, which naturally led him into the Tech Lead role. He sees the most difficult challenge in software as the social rather than the technical aspects.

以人为本——Sarah Taraporewalla

People Focus – Sarah Taraporewalla

Tech Lead 应该关注什么？为什么？

What should a Tech Lead focus on and why?

我一直在思考以下问题：

I think about the following questions all the time:

• 我的团队是否已尽其所能？我如何让每个团队成员发挥最大的作用？
• Is my team set up as well as it can be? And how do I get the best out of each team member?
• 每个团队成员是否知道、理解并相信同一个目标？
• Does each team member know, understand and believe in the same goal?
• 我是否允许他们有足够的空间来犯自己的错误和成长，但又不至于让项目脱轨？
• Am I allowing them enough room to make their own mistakes and grow, but not so much space that the project is derailed?
• 我是否营造了一个支持性的环境，让我的团队可以自由地挑战我的想法？
• Am I fostering a supportive environment where my team has the freedom to challenge me on my ideas?

作为 Tech Lead，您遇到的最大挑战是什么？

What has been your biggest challenge as a Tech Lead?

我在一个团队中，在我休假期间，五名开发人员翻了一番。每个人都有截然不同的技能和经验。我不认为我处理得像我希望的那样好，但我学到了很多东西。

I was on a team where the five developers doubled whilst I was away on holidays. Everyone had significantly different skills and experiences. I do not think I handled it as well as I would have liked, but I learned a lot.

我做的一件好事是确定团队的高级成员并向他们委派职能领域。他们与我合作提出了高级概念和设计，但由他们将其放入代码中并向团队其他成员解释。

One good thing I did was to identify the senior members of the team and delegated areas of functionality to them. They worked with me to come up with the high-level concept and design, but it was up to them to put it in code and explain it to the rest of the team.

因此，我与团队的某些成员密切合作，了解了他们担心的是什么，我应该关注的地方，他们想扩展自己的地方。但是我没有花足够的时间和更初级的成员在一起。我认为他们因此感到不那么欣赏和被听到。

As a result I worked closely with certain members of the team, and got to understand what was worrying them, where I should be concerned, where they wanted to extend themselves. But I did not spend enough time with the more junior members. I think they felt less appreciated and heard as a result.

有什么时间管理技巧吗？

Any time-management tips?

我使用故事墙让人们知道我在做什么。

I use the story wall to let people know what I am working on.

我通常让最高优先级（有时是“喊得最响亮的人”）决定我接下来要做什么，而故意拖延任何其他项目。

I usually let highest priority (sometimes the “loudest shouting person”) dictate what I am working on next and any other item purposely delay.

您如何在编写代码和处理其他问题之间取得适当的平衡？

How do you strike the right balance between writing code and dealing with other issues?

太难了！我发现自己要么重构代码以在即将到来的迭代中启用故事，要么为自己偷偷写一个新的小故事。根据团队的规模，我对代码所做的任何贡献通常不会影响整体进度，所以当我不在写故事时我不会烦恼。它让我腾出时间来确保我可以与某人结对讲述艰难的故事，或者看似拖沓的故事。这也意味着当我被拖去开会时，故事的流程不会被打断。

That’s hard! I find myself either refactoring code to enable stories in upcoming iterations, or sneaking a new, small story for myself. Depending on the size of the team, any contribution to code I make will not usually affect overall progress, so I don’t fret when I am not working on stories. It frees me up to make sure I can pair with someone on tough stories, or stories which seem to drag. It also means that when I am dragged off to meetings the flow of a story isn’t interrupted.

我专门留出时间坐下来配对，所以在某些日子可能没有会议预定。

I set time aside specifically to sit down and pair, so on certain days no meetings may be booked.

我总是乐于倾听讨论，以确定是否需要我；这样我就可以继续我正在做的事情，在我最需要减少时间的时候倾听并介入。

I constantly have an ear open to discussions to work out if I am needed or not; that way I can carry on what I am doing, listen in and step in when I am most needed to cut down on time.

Sarah 的关键问题：您是否曾经认为自己不是一名优秀的 Tech Lead？

Sarah’s key question: Was there ever a time when you thought that you weren’t a good Tech Lead?

是的，负载！特别是开始。但我认为，当你寻求改进的方法时，怀疑会让你在任何事情上都做得更好。在我作为 Tech Lead 的第一个大型团队中，我遇到了一次严重的信仰危机，我几乎告诉我们的资源管理部门不要让我担任 Tech Lead，因为我确信我做错了什么，但又想不通是什么。我就此咨询了某人，他说：“你可以避免成为 Tech Lead，或者你可以找出自己做错了什么并加以改正。你的队友怎么看你？” 我不知道答案，所以我开始与每个人进行反馈会议。结果他们认为我做得很好，但希望我多花点时间和他们在一起。所以我们一起学习：他们意识到我有疑虑，所以他们帮助了我，我们因此成为了更好的团队。

Yes, loads! Especially starting out. But I think that doubt makes you better at anything as you seek ways to improve. On my first large team as Tech Lead I had a crisis of faith that was so great I almost told our Resource Management not to make me Tech Lead, as I was certain I was doing something wrong, but couldn’t figure out what. I consulted someone about it, who said, “You could avoid being Tech Lead or you could find out what you are doing wrong and fix it. What do your team mates think of you?” I didn’t know the answer, so I started feedback sessions with everyone. It turned out that they thought I was doing a great job, but wanted me to spend a little more time with them. So we all learned together: they realised I was having doubts, so they helped me out and we became a much better team for it.

莎拉的背景故事

Sarah’s background story

Sarah 已经在 IT 行业工作了大约 10 年，毕业时在波音公司工作，三年后转到 ThoughtWorks。

Sarah has been working in IT for about 10 years, starting with Boeing as a graduate and then moving on to ThoughtWorks three years later.

在 Ben Butler-Cole (BBC) 的一个项目中，她作为二把手担任技术主管，并在她的下一个项目中再次描述了“非正式地担任技术主管的角色”。她随后的 Tech Lead 角色以更全面、更正式的身份出现。

She stepped into the Tech Lead role as the second in command on a project for Ben Butler-Cole (BBC) and describes “unofficially falling into the Tech Lead role” again on her next project. Her subsequent Tech Lead roles have been in a fuller, more official capacity.

参与团队——格伦·福特

Engaging the Team – Glen Ford

Tech Lead 应该关注什么？为什么？

What should a Tech Lead focus on and why?

作为 Tech Lead，我的目标是完成两件主要的事情：

As a Tech Lead, I aim to accomplish two main things:

• 为我的团队消除障碍：我解决阻碍我的团队或团队中个人的问题，无论是外部问题（例如阻碍利益相关者）还是内部问题（例如缺乏经验或知识）。
• Remove the obstacles for my team: I address the issues that are holding back my team or individuals in the team, whether that be external issues such as blocking stakeholders, or internal ones such as lack of experience or knowledge.
• 让自己变得多余：我努力确保团队拥有自我管理的技能、知识和经验。这有几个原因：我希望我的团队尽可能地自我组织；它给了他们更大的赋权感。这意味着团队可以在没有监督者的情况下运作，所以我有信心，如果我休假或生病，事情会顺利进行。同样重要的是，它也让我有时间去关注更广泛的问题，并在更高的层次上增加更多的价值。
• Make myself redundant: I work to ensure the team has the skills, knowledge, and experience to run itself. There are a couple of reasons for this: I want my teams to self-organise as much as possible; it gives them a greater feeling of empowerment. It means the team can operate without an overseer, so I can have confidence, should I go on leave or get ill, that things will operate smoothly. Just as importantly, it also frees me up to look at broader concerns and add more value at a higher level.

作为 Tech Lead，我主要担心的通常是人员参与。根据我的经验，技术问题很少是无法克服的。人的问题要复杂得多。

My main worries as a Tech Lead are usually about people engagement. Technical problems are rarely insurmountable, in my experience. People problems are much more complex.

作为 Tech Lead，您遇到的最大挑战是什么？

What has been your biggest challenge as a Tech Lead?

很难选择一个最具挑战性的情况。最近的挑战是领导一个由四名高级开发人员和技术架构师组成的强大团队，每个人都至少有 10 年的经验，并且都曾担任过技术主管。所有人都非常精通技术，而且都很固执己见。

It is difficult to select the single most challenging situation. The most recent challenge was leading a strong team of four senior developers and technical architects, each with at least 10 years’ experience and each had worked as Tech Leads in the past. All were very technically proficient and all opinionated.

该团队很快交付了一个原型，该原型随后投入生产，结果，由于技术债务和设计决策在接缝处分崩离析，这些设计决策在原型环境中有意义，但在生产中毫无意义.

The team had delivered a prototype very quickly, which had subsequently moved to production and, as a consequence, was falling apart at the seams with technical debt and design decisions that had made sense in the context of a prototype, but made no sense in production.

我面临的挑战是让团队参与并朝着一个单一的愿景努力；充分发挥不同性格的人，同时让团队中的每个人都畅所欲言并感受到团队的一部分。

The challenge I had was getting the team engaged and working to a single vision; getting the best out of different personalities, whilst keeping everyone on the team talking and feeling part of the team.

如果我不能在这个团队中展示我的技术能力，它就会分崩离析，但因为我赢得了他们的尊重，所以我能够让他们参与到我们面临的周围问题中。我明确表示，我的职责是消除他们的障碍，管理利益相关者，并为逐步改进系统扫清道路。作为回报，我希望每个人都专业，当他们觉得事情不对时说出来，并尊重共享所有权的想法。

If I hadn’t been able to show my technical competence with this team it would have fallen apart, but because I had earned their respect, I was able to engage them on the surrounding issues we faced. I made it clear that my role was to remove their obstacles, manage the stakeholders, and clear a path to incrementally improve the system. In return I expected everyone to be professional, speak out when they felt things weren’t right, and respect the ideas of shared ownership.

通过将团队中的每个人都视为独立个体并努力了解他们需要什么才能发挥最佳水平，我能够做出调整，这反过来又建立了团队情谊。例如，当这些权利受到倾向于退回到“座位上的流浪汉”的管理层的威胁时，我努力为那些远程工作良好的人保留在家工作的权利。

By treating everyone in the team as an individual and working to understand what they needed to perform to their optimum, I was able to make accommodations, which in turn built team camaraderie. For example, I fought hard to keep regular work-from-home rights for people who worked well remotely when these rights felt threatened by a management that tended to fall back on ‘bums on seats’.

我努力建立团队互动，我发现生产力显着提高。我们建立了一种“分歧不是批评”和“失败是学习界限所在”的团队文化。

I worked hard building team interactions and I found productivity grew significantly. We built a team culture of ‘disagreement is not criticism’ and ‘failure is learning where the boundaries are’.

每日站立会议通常很短；故事卡是简单的卡片，经过讨论和重写，直到每个人都理解为止。过程最少。我处理向利益相关者的报告，并确保没有没有价值的流程不会渗透到我们的工作方式中。每天好几次碰面（我们坐在一起）变得很普遍，因为我们会作为一个团队来解决具体问题。我们有时会结对编程，但没有明确规定。

Daily stand-ups were typically short; story cards were simple cards, which were debated and rewritten until everyone understood. Process was at a minimum. I dealt with reporting to stakeholders and ensuring that no process without value crept into how we worked. Huddles (we sat together) several times a day became common, as we would solve specific issues as a group. We pair-programmed on occasion, but not as an explicit rule.

当我担任领导角色时，该平台正在造成运营痛苦，我不得不避免重写、快速破解和其他“注入解决方案”的需求。我依靠我的团队和我自己的技术能力来反驳这一点，我明白我们需要看起来统一和一致。

When I stepped into the leadership role the platform was causing operational pain and I had to stave off demands for rewrites, quick hacks, and other ‘injected solutions’. I relied on my team’s and my own technical competence in rebutting this, understanding that we needed to look unified and in agreement.

我们将平台从不稳定的单一原型转变为分解后的稳健分布式平台，完全没有对最终用户造成任何干扰，我们还通过新功能和降低成本提供了商业价值。

We turned the platform around from unstable, monolithic prototype to decomposed robust, distributed platform without any interruption to end users at all and we also delivered business value through new features and reduced costs.

有什么时间管理技巧吗？

Any time-management tips?

提早开始让我有一个小时的时间来整理我当天的想法和计划。我会检查前一天未完成的任何事情，回顾任何紧急或重要的问题，其中我保留了三份待办事项清单：一份今天的，一份近期的，一份长期的。它只是帮助让事情对我可见。

Starting early gives me an hour to get my thoughts and plans for the day in place. I’ll go through anything outstanding from the previous day, review any urgent or important issues, of which I keep three to-do lists: one for today, one for near term and one for longer term. It just helps keep things visible to me.

我尝试面对面地处理问题，而不是冗长的电子邮件交流。在电子邮件交流中很容易浪费大量时间，这很容易被误解。

I try and deal with issues face to face, rather than lengthy email exchanges. It is easy to burn a lot of time in email exchanges, which are open to misinterpretation.

您如何在编写代码和处理其他问题之间取得适当的平衡？

How do you strike the right balance between writing code and dealing with other issues?

我倾向于处理非关键的小的离散编码片段，所以我不会妨碍任何团队成员。或者我与另一个人密切合作，结对或密切协作，这样我就可以无缝地交接。这通常很有效，因为我可以解决更多 Kaizen 类型的问题并减少可能会累积的摩擦，并且它有助于使我对代码库的了解保持最新。

I tend to work on small discrete pieces of coding that are non-critical, so I don’t hold up any team members. Or I work closely with another person, either pairing or close collaboration so that I can hand over seamlessly. This usually works well as I can address more Kaizen-type problems and reduce friction, which can otherwise build up, and it helps keep my knowledge of the codebase current.

我偶尔会为代表主要或复杂功能的工作进行深入编码。然而，在那些情况下，我确实发现很难平衡领导的需要和这种思想密集型工作所需的“心理空间”。

I have occasionally coded deeply for work that represents major or complex functionality. However, on those occasions I did find it much harder to balance the needs of leadership against the ‘mental space’ required for such thought-intensive work.

Glen 的关键问题：您是否接受过针对领导团队的任何培训或指导？

Glen’s key question: Have you received any training or mentoring specific to leading teams?

许多 Tech Lead 几乎没有接受过关于成为 Tech Lead 意味着什么，或者如何需要不同的思维方式的培训或指导。相反，我看到许多 Tech Leads 认为这个角色意味着必须比其他人做更多的时间；他们必须是团队中最好的开发人员。

Many Tech Leads have had little to no training or guidance in what it means to be a Tech Lead, or how it requires a different mindset. On the contrary, I see many Tech Leads thinking that the role means having to do more hours than everyone else; that they have to be the best developer in the team.

我在工程学位上接受的培训很少，但我很幸运在我的职业生涯中与一些伟大的人一起工作。

I received minimal training in my engineering degree, but I have been fortunate to have worked with some great people in my career.

格伦的背景故事

Glen’s background story

Glen 在获得电子工程学位后，在 IT 行业工作了 20 年。自 2000 年以来，他领导了大约七个团队，在领导和架构角色之间转换。

Glen has worked in IT for 20 years after graduating with a degree in electronic engineering. He has lead about seven teams since 2000, moving between leadership and architectural roles.

技术主管的技术

The Tech of a Tech Lead

如果没有角色技术方面隐含的责任，Tech Lead 的角色将不一样。同时，某些 Tech Lead 职责将此角色与开发人员的角色区分开来。

The role of Tech Lead would not be the same without the responsibility implied by the technical aspects of the role. At the same time, certain Tech Lead responsibilities distinguish the role from that of a developer.

指导技术解决方案

Guiding the Technical Solution

Tech Lead 的第一个区别职责是他们对技术解决方案的治理。此职责与技术架构师重叠，在许多组织中，这两个角色是相同的。

The first distinguishing responsibility of a Tech Lead is their governance of a technical solution. This responsibility overlaps with a Technical Architect and in many organisations these two roles are one and the same.

Tech Lead 制定整体技术解决方案，以确保满足所有要求。他们需要了解所有功能需求以了解可能构建的内容以及关于如何交付的跨功能需求 (CFR)。技术主管寻找重要的 CFR，这些 CFR 可能需要不同的架构或额外的工作来改进维度，例如可支持性或频繁部署。技术主管拥护所有相关的 CFR，并教育人们了解忽视它们的负面影响。

The Tech Lead shapes the overall technical solution to ensure that all requirements are met. They need to appreciate all the functional requirements to understand what might be built as well as cross-functional requirements (CFRs) about how it might be delivered. The Tech Lead looks for the significant CFRs that could require a different architecture or additional work to improve dimensions, such as supportability or frequent deployability. The Tech Lead champions all relevant CFRs and educates people about the negative impact of neglecting them.

CFR 会影响最终技术解决方案的形状，因此 Tech Lead 使用图表来传达团队内部的理解。

CFRs affect the shape of the final technical solution, so the Tech Lead uses diagrams to communicate understanding within the team.

协调团队方向

Harmonising Team Direction

当你有一组开发人员在一个系统上工作时，你会遇到开发人员不同意如何处理问题的情况。只要团队相对较快地确定一个方向，分歧就是健康的。当团队分裂时，分歧变得具有破坏性，无法在备选方案之间做出选择。

When you have a group of developers working on a single system, you will have occasions when developers disagree about how to approach a problem. Disagreements are healthy as long as the team settles on a direction relatively quickly. Disagreements become destructive when the team divides, unable to choose between alternatives.

当团队陷入僵局时，技术主管会仔细观察。他们使用不同的策略来寻找团队前进的方法，可能是促进、寻求外部建议，或者有时会介入做出决定。在这些情况下，技术主管首先寻求就要解决的核心问题达成一致，然后再考虑任何解决方案。只有当每个人都同意核心问题时，团队才能找到大家都同意的解决方案。

Tech Leads watch carefully when the team reaches an impasse. They use different strategies to find ways for the team to move forward, perhaps facilitating, reaching for external advice, or sometimes stepping in to make a decision. In these situations, a Tech Lead first seeks agreement on the core problem being solved, before entertaining any solutions. Only once everyone agrees on the core problem will the team find a solution agreeable to all.

技术负责人还会寻找表明开发人员可能朝不同方向发展的迹象。技术主管要注意何时有人不必要地添加另一种解决已知问题的方法。完成同一任务的不同方法会导致不必要的复杂性，并使集体代码所有权变得更加困难。和谐的团队看起来类似于编写代码库的单个开发人员，与以下不同：

A Tech Lead also looks for signs that indicate developers may be moving in different directions. Tech Leads watch out for when an individual unnecessarily adds another way of solving a known problem. Different methods of accomplishing the same task leads to unnecessary complexity and makes collective code ownership more difficult. A team in harmony looks similar to a single developer writing the codebase, unlike the following:

技术负责人为开发人员提倡设计原则和架构指南，以做出与整体技术解决方案保持一致的决策。

A Tech Lead promotes design principles and architectural guidelines for developers to make decisions that align with the overall technical solution.

管理技术风险

Managing Technical Risks

技术风险很快就会变成影响每个想要更改软件的人的问题，而不仅仅是开发人员。然而，只有具有技术背景的人才能感知风险并更准确地了解其影响。当风险成为现实并变成问题时，开发人员也是最先感受到影响的人。

Technical risks quickly turn into issues that affect everyone who wants to change software, not just the developers. However, only people with a technical background can sense the risks and more accurately understand their impact. Developers are also be the first to feel the impact when risks become real and turn into issues.

管理和跟踪技术风险的责任落在 Tech Lead 身上。就像项目经理跟踪和解决风险和问题的方式一样，技术主管与开发人员一起识别、确定优先级并找到减轻技术风险的方法。技术负责人让外部利益相关者和游说者更清楚地看到风险，以便花时间和资源来解决这些问题。

The responsibility for managing and tracking technical risks falls to the Tech Lead. Just like the way a project manager tracks and resolves risks and issues, the Tech Lead works with developers to identify, prioritise and find ways to mitigate technical risks. The Tech Lead makes risks more visible to outside stakeholders and lobbies for time and resources to address them.

技术负责人找到不同的方法来向非技术人员表达技术风险。技术主管使用隐喻和可视化向非技术人员解释冒险可能产生的影响。以非技术人员可以理解的方式表达技术问题可以创造更好的融洽关系并产生解决问题的支持。

The Tech Lead finds different approaches to express technical risks to non-technical people. The Tech Lead uses metaphors and visualisations to explain to non-technical people the impact that taking risks might have. Expressing technical issues in ways non-technical people can understand creates better rapport and generates support for fixing them.

解决技术风险或技术债务的倡导者必须来自团队内部，否则风险仍未得到解决。

The champion for addressing technical risks or technical debt must come from within the team or the risks remain unaddressed.

放眼长远

Taking a Longer-Term View

开发人员根据自己的经验、知识以及他们认为适合自己的方法解决问题。开发人员以狭隘的视角做出这个选择。Tech Lead 必须以更广阔的视角来处理问题；他们着眼于一个选择对团队中其他人的影响，以及该选择可以挽救或创造的未来工作或返工。技术负责人以更广泛、更长远的眼光评估决策。

A developer solves a problem based on their own experiences, knowledge, and what they think is right for them. A developer makes this choice with a narrow perspective. The Tech Lead has to approach problems with a wider perspective; they look at the consequences that a choice has on other people on the team, and the future work or rework that the choice could save or create. The Tech Lead evaluates decisions with a broader, longer-term view.

在前面关于新手的部分中，新的 Tech Leads 突然第一次意识到设计决策可能对系统的部署、架构和长期可维护性产生的影响。对开发人员来说可能很简单的事情可能会使在生产环境中运行软件变得更加困难，技术主管需要知道谁可能会受到该选择的影响，尤其是当他们不在团队中时。

In the earlier section on Novices, new Tech Leads suddenly became aware for the first time of the impact a design decision could have on deployment, architecture, and the long-term maintainability of the system. What may be simple for a developer could make running the software in production more difficult and a Tech Lead needs to be aware of who might be affected by that choice, particularly if they sit outside of the team.

如果今天的选择使明天更改或添加到系统变得更加困难，技术主管就会特别担心。Tech Lead 寻找机会让开发人员安全地接触到这种更广阔的视野，以提高开发人员对个人决策可能对未来产生的影响的认识。

A Tech Lead becomes particularly concerned if a choice today makes it more difficult to change or add to the system tomorrow. The Tech Lead finds opportunities to safely expose a developer to this broader view to grow the developer’s awareness of the impact an individual decision might have on the future.

团队和架构——Simon Brown

Teams and Architecture – Simon Brown

Tech Lead 应该关注什么？为什么？

What should a Tech Lead focus on and why?

Tech Lead 一词含糊不清：有些人认为 Tech Lead 是首席程序员；有些人将其视为软件架构师的同义词。我更喜欢 Software Architect，因为它暗示了一组责任，当您使用术语 Tech Lead 时，这些责任并不那么明显。

The term Tech Lead is ambiguous: some consider the Tech Lead to be the lead programmer; some see it as a synonym of software architect. I prefer Software Architect, because it implies a set of responsibilities that aren’t so obvious when you use the term Tech Lead.

无论您使用什么术语，该角色都应该专注于将软件系统的高级架构组合在一起，注意理解影响架构的任何需求或约束。架构需要随着时间的推移而发展，也需要将重点放在持续的技术领导上，以保护架构并确保技术质量。

Whatever term you use, the role should focus on putting together the high-level architecture of the software system, taking care to understand any requirements or constraints that influence the architecture. Architectures need to evolve over time and focus needs to be put on continuous technical leadership too, to guard the architecture and ensure technical quality.

要回答这个问题，我不得不说专注于让自己可以被替换。它是关于指导、协作和领导团队的。

To answer the question, I would have to say focus on making yourself replaceable. It is about coaching, collaborating with, and leading the team.

作为 Tech Lead，您遇到的最大挑战是什么？

What has been your biggest challenge as a Tech Lead?

我最大的挑战可能是当我被要求接管一个软件项目时，因为前任 Tech Lead 辞职了。从外部来看，该项目似乎拥有干净的架构，一支优秀的团队，他们有望在预算内交付，并在商定的时间范围内交付。仔细观察，情况就不同了。

My biggest challenge was probably when I was asked to take over a software project because the previous Tech Lead quit. From the outside, the project appeared to have clean architecture, a great team who were on track to delivering within budget, and agreed time scales. On closer inspection it was a different story.

我觉得架构过于复杂。未来战略被引用为原因，但迄今为止，该战略从未实施过！我努力简化架构，但在我认为不必要的系统部分上已经花费了太多。代码看起来也比应有的复杂，开发团队的成员抱怨内部分层策略的复杂性。很少有自动化测试；团队遵循的开发过程不明确，项目的总体范围也不明确。

I felt that the architecture was overly complex. Future strategy was cited as the reason for this, but to date, this strategy has never been implemented! I fought to simplify the architecture, but too much had already been spent on those parts of the system that I felt were unnecessary. The code looked more complex than it should have too, and members of the development team complained about the complexity of the internal layering strategy. There were few automated tests; the development process being followed by the team was ambiguous, and the overall scope of the project was vague.

我有一个选择：清理代码，编写测试并希望一切顺利，或者退后一步重新审视基础知识，例如项目范围和我们应该遵循的流程？我决定做后者，因为没有人清楚地知道已经完成了多少，或者还剩下多少要做。

I had a choice: clean up the code, write tests and hope that everything worked itself out, or step back and revisit the basics, such as the scope of the project and the process that we should follow? I decided to do the latter, as no one had a clear idea of how much had been completed, or how much was left to do.

我们与项目发起人一起设立了一些研讨会来定义高级范围。我们简化了架构；创建了一个看板来可视化剩余的工作；引入了“完成”的简单定义，并认真对待自动化测试。我们最终实现了目标，但这是我参与过的最令人沮丧的项目。

We set up some workshops with the project sponsors to define the high-level scope. We simplified the architecture; created a Kanban board to visualise the remaining work; introduced a simple definition of “done” and got serious about automated tests. We got there in the end, but it was the most frustrating project that I’ve ever been involved with.

它教会了我两个关键的事情：一个好的团队不仅仅是其各个部分的总和，而且并不是每个人都关注细节。我现在对担任领导职务的任何人的第一条规则是：永远不要做任何假设。

It taught me two key things: a good team is more than the sum of its parts, and that not everybody has attention to detail. My first rule now for anybody in a leadership role is: never make any assumptions.

有什么时间管理技巧吗？

Any time-management tips?

时间管理有很多技巧，包括“把事情做好”和“个人看板” 。我认为关键是要采取务实的态度来看待某事何时“完成”。当您编写或重构一些代码使其达到最佳状态时，您会感到难以置信的满足；诀窍是知道什么时候停止。自动化测试和验收标准确实在某种程度上起到了帮助作用，但“持续重构”确实需要一些限制。

There are lots of techniques for time management, including Getting Things Done and Personal Kanban. I think the key is to take a pragmatic stance of when something is “done”. It is incredibly satisfying when you’ve written or re-factored some code to be the best it can be; the trick is to know when to stop. Automated tests and acceptance criteria do go some way to helping here, but “continuous re-factoring” does require some limits.

文档之类的事情需要很多时间，所以我反复工作，在完成之前推出一些东西，以获得我正朝着正确方向前进的反馈。这是我会给任何人的建议：我们谈论使用敏捷和迭代方法构建软件，但这些方法在 Tech Lead 日常工作的其他方面也很有用。

Things like documentation take a lot of time, so I work iteratively, pushing stuff out before it is done, to get feedback that I am heading in the right direction. That’s the advice I would give anybody: we talk about building software using agile and iterative approaches, but these approaches can be useful in other aspects of a Tech Lead’s day job.

您如何在编写代码和处理其他问题之间取得适当的平衡？

How do you strike the right balance between writing code and dealing with other issues?

首先，不要承担超过你能处理的事情。其次，不要把自己放在交付代码的关键路径上。当然，这并不总是可能的，但请注意，您很容易成为瓶颈。第三，开放、指导和协作。分担 Tech Lead 角色（哪怕是一点点）可以分散其他烦人问题的压力，这些问题会占用您编写代码的时间。

Firstly, don’t take on more than you can handle. Secondly, don’t put yourself on the critical path with regard to delivering code. It’s not always possible, of course, but be aware that you can easily become the bottleneck. Thirdly, be open, coach, and collaborate. Sharing the Tech Lead role (even a little) spreads the pressure of other pesky issues that take away your time from writing code.

当您刚担任领导角色时，离开键盘可能会让人感到不舒服，但您不会因为每天离开 IDE（集成开发环境）几个小时而失去编码能力，所以不要让它担心你。

Stepping away from the keyboard can be uncomfortable when you first move into a leadership role, but you don’t lose the ability to code by stepping back from your IDE (integrated development environment) for a few hours a day, so don’t let it worry you.

Simon 的关键问题：您从哪里了解技术领导力，尤其是角色的软性方面？

Simon’s key question: Where do you learn about technical leadership, and particularly the softer side of the role?

这个话题没有考虑太多。软件行业中有很多关于敏捷和拥有自组织团队的讨论，而传统的软件架构观点阻碍了人们学习这门学科。虽然我同意我们当然应该努力实现自我组织，但我见过的大多数团队都离这个目标还有一段距离。他们面临的许多问题都可以通过一个专门的 Tech Lead 来解决。我推荐这些书：

This topic isn’t given much thought. There’s a lot of discussion in the software industry about being agile and having self-organising teams, and the traditional view of software architecture has discouraged people from learning about the discipline. While I agree that we should certainly strive to be self-organising, most teams that I’ve seen are some way from that goal. Many problems they face can be solved by having a single, dedicated Tech Lead. I recommend these books:

• 杰拉尔德·温伯格 (Gerald Weinberg) 成为技术领导者
• Becoming a Technical Leader by Gerald Weinberg
• Roy Osherove 给软件团队领导的笔记
• Notes to a Software Team Leader by Roy Osherove
• 演示禅：关于演示设计和交付的简单想法 Garr Reynolds
• Presentation Zen: Simple Ideas on Presentation Design and Delivery by Garr Reynolds
• Gamestorming：Dave Gray 等人的创新者、规则破坏者和变革者的剧本。
• Gamestorming: A Playbook for Innovators, Rulebreakers, and Changemakers by Dave Gray et al.

西蒙的背景故事

Simon’s background story

Simon 在多个行业的 IT 咨询公司工作了 12 年，逐渐成长为 Tech Lead 角色。四年前，他搬回了海峡群岛的泽西岛。

Simon has spent 12 years working for IT consulting companies in a broad range of industries, gradually growing into the Tech Lead role. He moved back to Jersey in the Channel Islands just over four years ago.

Simon 今天仍在编写代码，但他的更多工作是帮助团队理解软件架构、技术领导力以及找到敏捷性的平衡点。他目前正在撰写涵盖这些主题的一本书《面向开发人员的软件架构》 。

Simon still writes code today but more of his work is helping teams understand software architecture, technical leadership and finding the balance with agility. He is currently writing a book, “Software Architecture for Developers” that covers these topics.

实现和解决方案设计——Marten Gustafson

Enablement and Solution Design – Marten Gustafson

Tech Lead 应该关注什么？为什么？

What should a Tech Lead focus on and why?

支持和解决方案设计。

Enablement and solution design.

启用应该是首要的。确保团队有有效工作的空间；使其免受公司政治、无意义的会议和其他干扰的影响。同时，通过描述团队周围发生的事情、业务方向的变化或未来可能发生的事情来关注透明度。

Enablement should come first and foremost. Ensure the team has room to work effectively; shield it from company politics, pointless meetings, and other distractions. At the same time, focus on transparency by describing what is happening around the team, changes in direction from the business or what may be coming up in the future.

解决方案设计紧随其后。随着时间的推移，我尝试确定工作模式。我会问这样的问题：“我们是否多次编写相同的函数，如果是，我们可以合并不同的版本吗？” 或者“我们当前的数据存储是否适合其他数据？” 或者“我们应该对所有内容使用不同的语言，还是只对某些组件使用不同的语言？”

Solution design comes a close second. I try to identify work patterns over time. I ask questions such as: “Do we write the same function more than once and, if so, can we consolidate the different versions?” or “Is our current data store a good fit for other data?” or “Should we use a different language for everything, or just for certain components?”

我主要通过阅读或至少浏览所有新编​​写的代码并阅读新技术或评估框架来跟踪进度。

I track progress primarily by reading, or at least skimming all the newly written code and reading about new techniques or evaluating frameworks.

我花了很多时间思考可能会回来咬我们的延迟问题。诸如我们是否使用正确的数据版本控制持久数据策略，或者指标收集和日志保留等操作方面是否足够好等问题。我担心为开发团队提供足够的支持基础设施，例如构建服务器，或者缩短构建时间并使部署更顺畅。我考虑我们是否在稳定性、可用性和可伸缩性等质量方面花费了足够的时间。

I spend significant time thinking about deferred issues that could come back to bite us. Issues such as whether we’re using the right strategy for data versioning persistent data, or if operational aspects such as metric collection and log retention are good enough. I worry about having enough supporting infrastructure for the development team, such as build servers, or shortening build times and making deployments smoother. I consider whether we are spending enough time on quality aspects such as stability, availability, and scalability.

我试图培养一种文化，在这种文化中，开发人员不仅可以看到绿色单元测试，还可以观察可部署性、监控、指标和不断变化的服务器拓扑等操作方面。

I try to foster a culture where developers see beyond the green unit tests and also observe operational aspects such as deployability, monitoring, metrics, and changing server topologies.

我将其用作新手 Tech Lead 的原则列表：

I use this as a list of principles for a novice Tech Lead:

• 尽可能多地阅读代码
• Read as much code as possible
• 设置尽可能少的规则
• Set as few rules as possible
• 代码赢得争论
• Code wins arguments
• 做自己最严厉的批评家
• Be your own harshest critic
• 总是有更好的方法，但目前最可行的解决方案是什么？
• There’s always a better way, but what is the most feasible solution right now?
• 始终尽早解决运营方面的问题。
• Always address operational aspects early on.

我确保我们偶尔会做一些工作以外的事情，并尝试谈论工作以外的事情。

I make sure we do something outside work once in a while and try to talk about something other than work.

作为 Tech Lead，您遇到的最大挑战是什么？

What has been your biggest challenge as a Tech Lead?

向管理层解释迁移完整软件堆栈的复杂性，同时更换托管服务提供商。我认为我通过绘制依赖树做得相当好。我们必须这样做才能那样做，依此类推，一直到名为“DONE”的根节点。这是Mikado Method的粗略大变体。

Explaining to management the complexity of migrating a complete software stack, while switching hosting provider at the same time. I think I did fairly well by drawing a dependency tree. We have to do this in order to do that, and so on, all the way up to the root node named “DONE”. This is a coarse and large variant of the Mikado Method.

另一个挑战是处理糟糕的技术投资。看起来不错的技术，开始时很好，然后不久就崩溃了。你必须重新评估、重新调整并找到最佳替代路线。转换成本很容易被遗忘，尤其是动机的灰色地带：强制改变框架或实践会使您的团队失去动力还是会激发他们的活力？

Another challenge is dealing with bad technical investments. Techniques that look fine, start fine, and then come crumble shortly afterwards. You have to reassess, readjust, and find the best alternative route. The transition cost is easily forgotten, especially the grey area of motivation: does a forced change of a framework or practice de-motivate your team or does it energise them?

塑造整个团队以实现共同目标并遵守商定的最佳实践可能非常具有挑战性。当人们“深入研究”并专注于航运时，压力会更大。在可部署性、可操作性和整洁代码等基本技术质量上很容易失误。

Shaping the overall team to work against common goals and honour agreed best practices can be very challenging. It is harder under pressure when people “dig in” with a focus on shipping. It is easy to slip on basic technical quality such as deployability, operability, and clean code.

有什么时间管理技巧吗？

Any time-management tips?

我不相信自己会密切关注我的工作量。我把一切都写下来，因为这是唯一可以确定的方法。我每天和每周（汇总）更新电子表格。我每周记录对特定事件和显着成就的简短评论。

I don’t trust myself with keeping tabs on how much I work. I write everything down as it is the only way to be sure. I update a spreadsheet on a daily and weekly (in aggregate) basis. I record short comments on particular events and notable accomplishments per week.

其次，休假可能是一件好事，不仅对你而且对你的团队来说，因为他们在你不在的情况下开始工作。14 年后，我仍然很难请假；我绝对是我自己请假的最大障碍。

Secondly, time off can be a good thing, not just for you but for your team, as they get to work without you being around. After 14 years, I still struggle to take time off; I am definitely my own biggest obstacle to taking time off.

我尽量推迟计划，直到必须做某事，或者计划的感知需求已因环境变化而消失。推迟尽可能多的项目可以腾出时间进行代码审查和实际编程。

I try to defer planning as much as possible until something must be done, or the perceived need to plan has been obliterated by changed circumstances. Deferring as many items as possible frees up time for code reviews and actual programming.

您如何在编写代码和处理其他问题之间取得适当的平衡？

How do you strike the right balance between writing code and dealing with other issues?

如果你喜欢编程，你必须学会​​接受 Tech Leads 有战斗，会有起伏。如果我觉得非编程任务能让团队更好地完成工作，我会优先考虑这些任务。我学会了更好地处理干扰，因为 Tech Lead 是一个协调点。我清楚自己想要什么以及实现它的先决条件。

If you enjoy programming, you have to learn to accept that Tech Leads have a battle and there will be ups and downs. I prioritise non-programming tasks if I feel it enables the team to do their job better. I have learned to handle interruptions better, because the Tech Lead is a point of coordination. I am conscious of what I want and the prerequisites for making it happen.

找到你的力量动物。当我因过多的多项任务而感到压力时，我会筛选技术问题以找到一些小的且相对容易做的事情。我放下所有东西几个小时并修复它。发布修复问题的代码，无论多么小，都会很快让我心情好起来。

Find your power animal. When I am stressed by too much multi-tasking, I sift through technical issues to find something small and relatively easy to do. I drop everything for a couple of hours and fix it. Shipping code that fixes something, however small, quickly puts me in a better mood.

编者按：力量动物是萨满教的概念：它是一种赋予人力量并保护人免受伤害的精神。

Editor’s note: A power animal is a shamanic concept: it is a spirit that empowers and protects a person from harm.

Marten 的关键问题：关于组织和规划软件开发，您有哪些原则和信念？

Marten’s key question: What principles and beliefs do you have around organising and planning software development?

我相信自我组织；显然，在我的团队中，但理想情况下，在组织中也从事开发工作的其他部分。我坚信相对估计，但最好不要根据故事点。我努力进行公开讨论，让受影响的人，无论其组织隶属关系如何，就前三到五个优先事项达成一致。

I believe in self-organisation; within my team, obviously, but ideally in other parts of the organisation that work with development too. I’m a firm believer in relative estimation, but preferably not in terms of story points. I strive for an open discussion where the affected people, regardless of organisational affiliation, reach an agreement on the top three to five priorities.

然后人们自组织地完成该列表，必要时将项目分解为更小的任务。团队根据需要制作原型、测试和发布。我不喜欢使用日历截止日期或固定发布窗口。

People then self-organise to work through that list, breaking items down into smaller tasks if necessary. The team prototypes, tests, and releases as necessary. I prefer not to work with calendar deadlines or fixed-release windows.

我认为最大的挑战是找到最初的机会来证明这种工作方法是成功的。

I think the biggest challenge is finding the initial opportunity to prove this method of working is successful.

Marten 的第二个关键问题：您如何与那些不懂编程的人或组织的那些部分一起工作？

Marten’s second key question: How do you work with those people or those parts of the organisation that don’t understand programming?

我的方法取决于组织的类型以及我拥有什么样的授权和自主权。我邀请组织的其他部分参与规划和跟进过程。让他们参与到流程中可以证明估算小时数或设置日期是多么毫无意义，并且表明最好将时间花在开发和找出真正需要解决的需求上。

My approach depends both on the type of organisation and what kind of mandate and autonomy I have. I invite other parts of the organisation to the planning and follow-up process. Involving them in the process demonstrates how pointless it is to estimate the number of hours or to set dates and it shows that time is better spent developing and finding out what requirements really need addressing.

马腾的背景故事

Marten’s background story

Marten 是一名瑞典软件开发人员，过去 14 年一直从事后端、数据存储和基础设施垂直领域的工作。此前，他曾在瑞典最大的网站之一的 12 人团队中担任技术主管。他发现目前担任较小团队的技术主管角色需要更多的实际操作。

Marten is a Swedish software developer and has worked in backend, datastore and infrastructure verticals for the past 14 years. Previously, he played the Tech Lead role for one of Sweden’s largest websites for a team of 12. He finds his current Tech Lead role for a smaller team requires much more hands-on work.

管理技术债务——Mark Crossfield

Manage Tech Debt – Mark Crossfield

Tech Lead 应该关注什么？为什么？

What should a Tech Lead focus on and why?

设计！作为 Tech Lead，开发中最令人担忧的方面是技术债务，以及引入混乱的代码和耦合，这可能会减慢团队的速度。我审查团队的设计决策；我的意见是提供连续性和不同的视角。确保整个团队朝着同一个方向前进并对代码库有相同的理解需要了解历史背景。了解工艺的细节会有所帮助，例如知道引入概括和抽象的适当时间。

Design! As a Tech Lead the most worrying aspect of development is technical debt, and the introduction of messy code and coupling, which potentially slows the team down. I review the team’s design decisions; my input is to provide continuity and a different perspective. Ensuring the whole team is going in the same direction and has the same understanding of the code base requires knowledge of the historical context. An appreciation of the finer points of the craft helps, such as knowing the appropriate times to introduce generalisation and abstraction.

我会把我的原则描述为精益和负责任。我认为开发人员应该对整个过程负责：从捕获需求到交付并确保功能在生产中继续发挥作用。我不相信将交付学科分开；它们本质上是交织在一起的，人们应该尽其所能做出贡献。每个开发人员都需要考虑他们所做的每项行动或不作为的影响。技术负责人必须确保交付价值，我发现自己要确保交付变革的团队也在交付价值，而不是探索自己的兴趣。

I would describe my principles as lean and responsible. I believe developers should own responsibility over the whole process: from capturing requirements through to delivery and assurance that a feature continues to work in production. I don’t believe in separating out delivery disciplines; they are intrinsically entwined and people should contribute wherever they can. Every developer needs to consider the impact of each action or inaction they make. A Tech Lead must ensure that value is delivered and I find myself ensuring that a team delivering a change is also delivering value, rather than exploring its own interests.

作为 Tech Lead，您遇到的最大挑战是什么？

What has been your biggest challenge as a Tech Lead?

我很难找出一个比其他挑战更大的挑战。我认为我最大的挑战是协同设计。对于大型代码库，团队必须考虑其所做决策的影响，并且这些决策不是孤立做出的。我发现大多数人倾向于推迟设计或将其留给其他人。

I struggle to identify one challenge greater than the rest. I think my biggest challenge is collaborative design. With a large code base it is important for the team to consider the impact of the decisions that it makes, and that these decisions are not made in isolation. I have found that most people tend to put off design or leave it to someone else.

不想支配设计决策，感觉乐观并且没有大量的技术领导经验，我在这个领域给了团队相当多的自由和自主权。虽然这使团队能够迅速扩大规模，但我们感受到了连锁反应，因为我们因代码的许多部分的脆弱性而放慢了速度。我发现外部开发教练很有帮助，而且我正在慢慢寻找可用于帮助找到更好解决方案的概念工具，例如Hexagonal Architecture和Connascence以及协作绘图和白板会议，以确保每个人都在同一页面上。委派一些技术责任也有帮助，因为它使我能够快速将设计问题传达给一个人，并让他们在子团队内提供连续性。

Not wanting to dictate design decisions, feeling optimistic and not having a huge amount of experience in technical leadership, I gave the team quite a lot of freedom and autonomy in this area. While this allowed the team to scale up quite quickly, we felt the knock-on effects as we were slowed by the fragile nature of many parts of the code. I have found external development coaches helpful, and I am slowly finding conceptual tools that can be used to help find better solutions such as Hexagonal Architecture and Connascence along with collaborative drawing and whiteboard sessions to ensure everyone is on the same page. Delegating some technical responsibility helps too, as it allows me to quickly communicate a design issue to one person and have them provide continuity within the sub team.

有什么时间管理技巧吗？

Any time-management tips?

分类是一个重要的策略。在大型团队中，以最有效的方式利用您的时间非常重要。当有人需要谈话时，我会在开始之前先弄清楚一些事情：他们想谈什么？还有谁需要参与？那个人是不是因为等我而被挡住了，需要多长时间？我试图确定的是，如果我延迟或什至不参与会产生什么影响。如果我面临压力，我会要求人们在几分钟或几小时内联系我。如果我要优先考虑其他事情，我会尝试保留等待我的人的名单，以确保对话不会被遗忘。我使用 TeuxDeux，但正在考虑转向 Trello。当上下文切换很多时，我的短期记忆力很差，如果我可以依靠技术来提醒我需要与谁交谈，我会发现压力会小得多。跟踪未解决和即将发生的问题很重要，因为它们经常被遗漏——尤其是在交付时间紧迫的情况下。

Triage is an important tactic. In a large team it is important to use your time in the most efficient way. When someone needs to talk, I try to find a few things out before committing: what is it they wish to talk about? who else needs to be involved? Is the person blocked by waiting for me, and how long will it take? What I try to establish is what would be the impact if I delayed or were not even involved. If I am under pressure I ask people to approach me in a few minutes or a few hours. If I am prioritising something else, I try to keep the list of people who are waiting for me, to ensure that the conversation isn’t forgotten about. I use TeuxDeux, but am considering a move to Trello. I have a terrible short-term memory when context-switching a lot, and find it much less stressful if I can rely on technology to remind me who I need to have conversations with. It is important to keep track of unresolved and impending issues, because too often they fall through the cracks - especially when delivery schedules are tight.

当我不讨论更改时，我会尝试确保我花时间做的事情与目标保持一致。目标可能是提高稳定性、降低复杂性、传播知识或提高可见性。很容易被你正在做的事情所吸引，而无法为团队提供价值。我特别容易被一个问题迷住，这是 Tech Lead 所没有的奢侈；他们的可用性往往是迫切需要的，所以深度潜水应该是例外而不是规则。

When I am not discussing a change, I try to ensure that what I spend my time on is aligned to a goal. The goal may be improving stability, reducing complexity, spreading knowledge, or improving visibility. It is easy to become absorbed by what you are doing and stray from providing value to the team. I am particularly prone to being fascinated by a problem, which is a luxury that a Tech Lead does not have; their availability is often required urgently, so deep dives should be the exception rather than the rule.

一位导师给我的最好的时间管理建议是弄清楚哪些问题会产生最大的影响，以及哪些问题的解决会提供最大的价值。

The best piece of time-management advice I was given by a mentor is to work out which issues will have the most impact, and so which would provide the most value by being resolved.

您如何在编写代码和处理其他问题之间取得适当的平衡？

How do you strike the right balance between writing code and dealing with other issues?

我不会说我已经找到了平衡点！我宁愿写更多的代码，我认为这样做会更容易改进设计，但我的其他职责占用了相当多的时间。

I would not say I have found a balance yet! I would rather be writing more code than I do, and I think it would be easier to improve design by doing so, but my other responsibilities take up quite a lot of time.

也就是说，我认为 Tech Lead 可以做的最重要的事情就是与另一个团队成员一起探索问题并找到解决方案。通过配对，您可以最大限度地减少在需要时躲避的影响。

That said, I think the most important thing a Tech Lead can do to balance their time is to pair with another team member to explore a problem and find a solution. By pairing, you can minimise the impact of ducking out as and when required.

关键是尽量不要做太多；承担责任不可避免地会让你离开代码库，而实际上，你可能是最有资格从事代码库工作的人之一。

The key is to try not to do too much; taking on responsibilities inevitably takes you away from the code base when, realistically, you are probably among the most qualified to work on it.

尽可能委托任何非编码任务，但要建立界限和监督。我发现情境领导理论很有用，每当我委派任务时，我都会考虑这个人的意愿和能力。这有助于决定您需要多密切地监督他们的工作。

Where possible delegate whatever non-coding tasks you can, but establish boundaries and supervision. I found situational leadership theory useful, and whenever I delegate I consider the person’s will and ability. This helps decide how closely you need to supervise their work.

Mark 的关键问题：“哪些关键技术原则是 Tech Leads 的基本知识？”

Mark’s key question: “What key technical principals are essential knowledge for Tech Leads?”

我认为了解长期和短期决策之间的区别很重要。例如，从长远来看，外部通信协议和数据结构（如 JSON、RESTful 方法、HTTP 或 SOAP）比内部应用程序选择（如语言选择、​​TDD 或持久性框架）更重要。

I believe it is important to understand the difference between long-term and short-term decisions. For example, external communication protocols and data structures such as JSON, RESTful approaches, HTTP, or SOAP are more important in the long run than internal application choices such as language choice, TDD, or persistence framework.

我建议 Tech Leads 了解分层架构、六边形架构的原则、领域驱动设计、关于 Connascence 的想法以及围绕重构以删除它的技术。

I recommend Tech Leads understand layered architecture, the principles of hexagonal architecture, domain-driven design, and the ideas around Connascence as well as techniques around refactoring to remove it.

马克的背景故事

Mark’s background story

Mark 是 Trader Media (Auto Trader) 的技术架构师，作为开发人员工作了八年。在过去的四年里，他一直担任技术主管，目前与一个由 16 名开发人员组成的团队参与一个长期项目。

Mark is the Technical Architect for Trader Media (Auto Trader) and has worked as a developer for eight years. He has worked as a Tech Lead for the last four years currently with a team of 16 developers on a long-term project.

他的兴趣包括系统设计、数据可视化、监控和弹性以及软件质量，尽管他对代码工艺以及语言和计算的学术方面特别感兴趣。

His interests include system design, data visualisation, monitoring and resilience, and software quality, although he is particularly interested in code craftsmanship and the academic aspects of language and computing.

也是建筑师？– 托米瓦内克

An Architect Too? – Tomi Vanek

Tech Lead 应该关注什么？为什么？

What should a Tech Lead focus on and why?

Tech Lead 的责任有两个方面：技术和人。

There are two dimensions to the Tech Lead’s responsibility: technology and people.

在技​​术方面，Tech Leads 面临复杂的挑战，需要直觉来识别根本原因；他们不能因症状而分心。Tech Lead 的架构师部分指定解决方案的形状、模式、内部结构、逻辑，并持有地图。Tech Lead 通过与团队的设计讨论构建此地图，然后与团队一起实施。该体系结构应及时指定，因此它具有最少的固定形状。技术负责人确保架构在系统的整个生命周期内不断发展。我认为建筑就像一个人的身体，一开始长得很快，到成年才保持完好，知道什么时候让位给下一代。

In terms of technology, Tech Leads face complex challenges that require intuition to recognise the root cause; they cannot be distracted by symptoms. The architect part of the Tech Lead specifies the shapes, patterns, inner structure, logic of the solution, and holds the map. The Tech Lead builds this map through design discussions with the team and then implements it with the team. The architecture should be specified just in time, so it has minimum fixed shapes. The Tech Lead ensures the architecture evolves throughout the lifetime of the system. I think of architecture as like a human body: it grows quickly at the beginning, in adult age it is kept in good shape, and knows when to give way to the next generation.

就人而言：技术主管必须倾听和观察团队，以收集关键信息以做出正确的决策。他们还需要了解文化、历史背景以及开发和维护软件系统的人员。一个系统需要适应它所处的文化，特别是考虑到那些将继续开发和维护它的人。技术负责人还必须针对构建软件的团队调整开发过程。他们必须欣赏每个人都有自己的梦想、悲伤和独特的个性。在短时间内，Tech Lead 必须为团队中的每个人找到合适的角色，并为团队带来和谐的节奏。

In terms of people: Tech Leads have to listen and observe the team to gather the critical mass of information to make the right decisions. They also need to understand the culture, historical background, and the people who developed and maintain the software system. A system needs to be adapted to the culture it lives in, particularly considering those who will continue to develop and maintain it. The Tech Lead must also adjust the development process to the team that builds the software. They must appreciate each person has their own dreams, sorrows, and unique personality. In a short space of time, the Tech Lead must find the right role for each person in the team and bring a harmonised rhythm to the team.

作为 Tech Lead，您遇到的最大挑战是什么？

What has been your biggest challenge as a Tech Lead?

我为客户指导了一个架构团队。该团队使用复杂的架构，这使开发陷入瘫痪。这意味着开发团队无法交付新功能或应用程序。团队知道架构很痛苦，但这是他们的宝贝；有些人认为它的复杂性证明了他们的技术专长；对于其他人来说，它代表着工作保障。

I coached an architecture team for a client. The team worked with a complex architecture, which paralysed development. It meant that the development team couldn’t deliver new features or applications. The team knew the architecture was painful, but it was their baby; some felt its complexity demonstrated their technical expertise; for others, it represented job security.

我觉得同意一些基本价值观以推出新架构很重要。我们选择了简单。我们与客户的架构团队一起开发了它，因此他们对其进行了一些情感投资，并感受到了对新系统的主人翁意识。

I felt it was important to agree some basic values to roll out a new architecture. We settled on simplicity. We developed it together with the client’s architecture team so they had some emotional investment in it and felt ownership for the new system.

旧架构的一个核心功能是锁定以防止同时编辑相同的数据。这是典型的老式面向对象编程。该功能需要大约 50 个类、深层次的继承链，并且为了以防万一，功能过于臃肿。

A core feature of the old architecture had been locking to prevent concurrent editing of the same data. This was typical old-school, object-oriented programming. The feature required about 50 classes, deep inheritance chains, and was bloated with functionality, just in case.

我向团队建议我们专注于生产中应用程序使用的功能。架构师同意并开始删除未使用的功能，只保留两三个必要的类。新服务不需要任何进一步的解释，因为它们简单明了。

I suggested to the team that we focus on features used by applications in production. The architects agreed and started to remove unused functionality, preserving only the two or three classes necessary. New services did not require any further explanation, as they were clear and simple.

有什么时间管理技巧吗？

Any time-management tips?

管理时间很难；我一直在寻找更好的方法来做到这一点。

Managing time is hard; I am constantly looking for better ways to do it.

我最简单的方法是处理具有相同粒度的优先级积压任务。然后，我在板上为团队和外部利益相关者可视化系统，以展示我正在做的事情。任务完成、进行中或等待的视觉感使团队和利益相关者更容易看到我在做什么。

My simplest method is to work with a prioritised backlog of tasks of the same granularity. I then visualise the system on a board for the team and external stakeholders to demonstrate what I am working on. A visual sense of tasks completed, in progress, or waiting makes it easier for the team and stakeholders to see what I am working on.

我每天都会抽出一些时间在互联网上阅读科技新闻。我抽出时间在上下班途中阅读。

I set aside some time in my day to read technology news on the internet. I find time to read on my commute to and from the office.

您如何在编写代码和处理其他问题之间取得适当的平衡？

How do you strike the right balance between writing code and dealing with other issues?

作为一名开发人员，我处理 Tech Lead 任务的方式与往常一样。看开发过程就像找算法一样。了解编写功能规范的分析师与开发人员之间的沟通问题就像调试一样。但是，当 Tech Lead 离开编码时，他们无法识别和修复某些问题。

I approach my Tech Lead tasks much as I always did as a developer. Looking at the development process is like finding an algorithm. Understanding communication problems between analysts writing functional specifications and developers is like debugging. However, when a Tech Lead moves away from coding, they cannot identify and fix certain issues.

我留出时间写代码。我还问自己是否真的需要我关注某项特定任务。我尝试与其他团队成员一起解决这些问题，以便解决方案在我自己的影响之外持续存在，并且团队会随着时间的推移不断发展和完善解决方案。

I set time aside to write code. I also ask myself whether a particular task really requires my attention. I try to work on these together with other team members so the solution lasts beyond my own influence and the team evolves and refines the solution over time.

Tomi 的关键问题：您如何看待五年后的自己？

Tomi’s key question: Where do you see yourself five years from now?

我真的不知道 ？这就是我们所做的令人兴奋的事情！

I really do not know ? that’s the exciting thing about what we do!

托米的背景故事

Tomi’s background story

Tomi 从事软件工作超过 25 年，在过去的 15 年中与各种团队合作。从核电站使用的软件到现代 Web 应用程序和门户，他的工作涉及方方面面。

Tomi has worked with software for more than 25 years and with a variety of teams for the past 15 years. He has worked in everything from software used in nuclear power plants to modern web applications and portals.

他目前的兴趣是开发一种“及时”的软件架构方法，并使用敏捷方法在团队级别进行编程。

His current interest is developing a “just in time” approach to software architecture and using agile methods to program at a team level.

冠军品质——彼得·莫兰

Champion Quality – Peter Moran

Tech Lead 应该关注什么？为什么？

What should a Tech Lead focus on and why?

我的大部分想法集中在两个主要问题上：

I focus most of my thoughts on two main concerns:

• 如何在人们身上培养良好的软件设计原则和实践；
• How to develop good software design principles and practices in people;
• 如何充分利用团队合作的技术专家。
• How to get the best out of technologists working together in teams.

当您的人员非常了解他们的技术以及如何明智地应用它，并且他们有动力并且可以与周围的人协作时，您就拥有了高性能软件交付的基础。这些是可以在合适的环境和合适的领导下培养的后天技能；我认为一个好的 Tech Leader 需要努力去培养他们，帮助个人和团队在这些领域的能力成长。

When you have people who know their technology well and how to apply it sensibly, and they are motivated and can collaborate with those around them, you have the basis for high-performing software delivery. These are learned skills that can develop in the right environment with the right leadership; I believe a good Tech Leader needs to work hard to foster them and help individuals and teams grow in their capabilities in these areas.

作为 Tech Lead，您遇到的最大挑战是什么？

What has been your biggest challenge as a Tech Lead?

对我来说，这就是带领一个由 25 名人才组成的团队在巨大的时间压力下交付一个全新的、备受瞩目的网站。技术挑战是在不牺牲允许系统扩展、维护和长期运行的良好设计原则的情况下保持高质量和高吞吐量。在压力下保持较低的技术债务非常困难。人员方面是为了让有才华的技术人员（开发人员、测试人员、运维管理员）有动力坚持他们的原则并看到更大的目标，同时功能不断增加，复杂性也在增加。平衡这些有时相互竞争的目标极具挑战性。应对挑战（而不是我总是擅长的事情）的一个关键是沟通。例如：

For me, this was leading a team of 25 talented people to deliver a new, high-profile website under heavy time pressures. The technical challenges were keeping both quality and throughput high without sacrificing the good design principles that allow a system to be extended, maintained and to perform over a long period of time. Keeping technical debt low while under pressure is extremely hard. The people aspects were to keep talented technologists (developers, testers, ops administrators) motivated to stick to their principles and see the bigger goal, while features were stacking up and complexity grew. Balancing these sometimes competing objectives was extremely challenging. One key to handling the challenges (and not something I always do well) was communication. For example:

• 让人们了解情况
• Keep people informed
• 寻求持续的反馈
• Seek constant feedback
• 花时间与尽可能多的团队成员讨论技术问题
• Take time to discuss technical issues with as many team members as possible
• 尽量减少意外
• Minimise surprises
• 确保团队中的每个人都了解您要实现的目标
• Make sure everyone on the team understands the objectives of what you are trying to achieve
• 让每个人都有发言权；和
• Give everyone a voice; and
• 准备好为团队告诉你的事情而战。
• Be prepared to fight for what the team tells you.

有什么时间管理技巧吗？

Any time-management tips?

我依赖于保留一小部分要做的事情并确保我每天都完成它们。我还发现让我的电子邮件收件箱保持清空很有帮助（我认为没有未读的电子邮件是空的）。我发现我需要学习何时退出。参与一系列技术问题、业务讨论或人员管理任务是可以的，但我需要知道何时放手并相信其他人会完成这些任务。

I rely on keeping a small list of things to do and making sure I complete them each day. I also find it helps to keep my email inbox empty (I consider no unread emails as being empty). I’ve found that I needed to learn when to back out of things. It is ok to get involved in a range of technical issues, business discussions, or people management tasks, but I need to be aware of when to let go and trust others to take them to completion.

您如何在编写代码和处理其他问题之间取得适当的平衡？

How do you strike the right balance between writing code and dealing with other issues?

我意识到我不会像我想的那样频繁地编写代码，但我会留出时间来确保我这样做。我会选择有用但不依赖时间的小功能或问题，我每周会花几个小时来完成它们。我尝试每周至少配对一次；我可以参与一个故事，因为我知道如果我被转移了，还有其他人可以参与其中。这是跟上代码库和学习新实践和技术的好方法。我也使用代码作为治疗方法；只要有机会，我就会编写代码，因为我会感觉更好，而且我有信心可以通过一些小的方式改进代码库。

I realise that I will not get to code as often as I want, but I put time aside to make sure I do. I will pick up small features or issues that are useful but not time-dependent and I spend a couple of hours each week getting them done. I try to pair at least once a week; I can get involved in a story knowing that if I am diverted there is someone else to run with it. This is a great way of keeping up with the codebase, and learning new practices and techniques. I also use code as therapy; whenever I have a window of opportunity, I’ll code, because I’ll feel better for it, and I am confident I can make the codebase better in some small way.

Peter 的关键问题：您如何保持技术人员的积极性？

Peter’s key question: How do you keep your technical people motivated?

Drive的作者 Dan Pink对此有很好的见解，我一直在密切关注他的方法。不过，他没有涵盖一个重要方面：使一群人有效合作的人际关系。

Dan Pink, author of Drive has really good insights on this, and I’ve followed his approach closely. He doesn’t cover one important aspect, though: the personal connections that make groups of people work effectively together.

彼得的背景故事

Peter’s background story

Peter 是Hooroo.com的开发经理。他的职责包括在技术、流程和人员等各个方面领导交付团队。在此之前，他在大约 15 个不同的团队和项目中担任技术主管。

Peter is the Development Manager at Hooroo.com. His role includes leading the delivery team in all aspects - technical, process, and people. He acted as the Tech Lead role on about 15 different teams and projects before that.

Peter 本质上是一名软件开发人员，他非常注重提高自己的技术技能，因为相关技能可以帮助他更有效地领导团队。他的兴趣继续在于精心设计的面向对象软件和开发技术娴熟、积极进取的团队以有效交付。

Peter is a software developer at heart and takes great care in sharpening his technical skills, as relevant skills help him more effectively lead teams. His interests continue in well-designed object-oriented software and developing skilled, motivated teams that deliver effectively.

不要忘记跨职能需求——Christy Allmon

Don’t Forget Cross-Functional Requirements – Christy Allmon

Tech Lead 应该关注什么？为什么？

What should a Tech Lead focus on and why?

我作为 Tech Lead 的角色会根据团队规模、日常活动、我自己的日常活动以及我们所处的开发周期阶段而变化。总的来说，我认为我目前的角色是应用程序的 SME（每个人——分析师、开发人员、Scrum Master、测试人员、集成团队和客户——带着问题和问题来找我），以及决定优先级和技术的人/要采取的应用方向。

My role as Tech Lead changes depending on the team size, its day-to-day activities, my own day-to-day activities, and what stage of the development cycle we are at. In general, I think my current role is SME for the Application (everyone – Analysts, Developers, Scrum Master, Testers, Integration Teams, and Customers – comes to me with questions and problems), as well as person who decides the priorities and technical/application direction to be taken.

我最关心的原则是： - 可维护性：代码必须是可维护的！我认为一些开发人员和承包商没有考虑到其他人必须在他们之后进来并且需要能够维护和排除代码故障的事实。现在有很多可用的工具可以帮助衡量这一点，但在遗留系统和开发工作中，我的经验是，应用程序的好坏取决于它的可维护性。

The principles that concern me the most are: - Maintainability: the code has to be maintainable! I think some developers and contractors don’t consider the fact that others have to come in after them and need to be able to maintain and troubleshoot the code. A lot of tools that are now available can help with measuring this, but having been on legacy systems as well as development efforts, my experience has been that an application is only as good as its maintainability.

• 硬编码：尽你所能避免硬编码。如果有任何方法可以避免硬编码根据我的经验会改变的值，那就去做吧！如果它是基于客户端的（我在 Java Swing 胖客户端上工作），请将其放在属性或其他类型的文件中。如果它是基于服务器的（应用程序的后端），请将其放入数据库或提供某种客户端触发的事件。即使你认为它永远不会改变，它也不可避免地会改变。
• Hard coding: do everything you can to avoid hard coding. If there is any way at all to avoid hard coding a value that, in my experience, will change, do it! If it is client-based (I work on Java Swing fat client), put it in a property or other kind of file. If it is server-based (backend of the application), put it in a database or provide some kind of client-triggered event. Even if you think it will never change, it inevitably will.
• 性能：我经常需要提出建议并验证代码的逻辑是否考虑了性能。例如，如果您多次加载或处理数据，请注意只执行一次静态操作。在适用的情况下，还要考虑按需或即时处理。
• Performance: I often have to make suggestions and verify that performance has been considered in the logic of the code. For example, if you are loading or processing data multiple times, be mindful of doing the static stuff only once. Also consider on-demand or just-in-time processing where applicable.
• 稳定性：权衡特定变化的风险与其可能对稳定性产生的影响。我的承包商开发人员经常对引入新方法或工具提出很好的建议，但我必须权衡利弊。
• Stability: weighing up the risk of a particular change against the impact it may have on stability. My contractor developers often have good suggestions for bringing in new approaches or tools, but I have to weigh up the benefits against the risks.

作为 Tech Lead，您遇到的最大挑战是什么？

What has been your biggest challenge as a Tech Lead?

我不得不说，我目前所处的情况是我迄今为止最具挑战性的。我典型的一天涉及太多的会议或团队讨论，以至于我不得不不断地切换上下文，我发现很难完成任何特定的任务。最重要的是，我很少有机会编写代码，这是我工作中真正喜欢的部分，老实说，这是我真正擅长的部分。我正在尝试在事情出现时进行越来越多的教学，以便我的团队能够更加自给自足并互相帮助，而不是依赖我。我正在努力授权更多，以便我有时间处理重要的事情，并让我回到可以为做一些编码做出贡献的状态。过去，我经常做很多我喜欢称之为“繁重”的编码工作：需要我的专业知识和技能的应用程序的复杂或关键部分。由于我们目前所处的环境，我已经好几个月没能做到这一点了，但我希望能尽快回到那个状态。

I would have to say that the situation I am currently in is my most challenging yet. My typical day involves so many meetings or team discussions that I am in a constant flux of having to context switch and I find it difficult to complete any particular task. On top of that, it is rare that I get a chance to code, which is the part of my job that I really enjoy and honestly what I am really good at. I am trying to do more and more teaching as things as they come up so that my team can be more self-sufficient and help each other instead of relying on me. I am working on delegating more so that I have time for the important things and to get me back to a state where I can contribute with doing some of the coding. In the past, I often did much of what I like to call “heavy lifting” coding: the complex or critical pieces of the application that required my expertise and skills. I haven’t been able to do that for quite a few months due to the environment we are currently in, but I hope to get back to that soon.

有什么时间管理技巧吗？

Any time-management tips?

我必须确定优先顺序，以便管理对我的时间的需求；我必须对某些事情说不，或者委派我能做的。我也知道在发布周期中有时需要加班。它是周期性的，是工作的一部分，如果你明白它最终都会水落石出；你可以管理它。我的家人已经开始学习这个重要的概念，并且知道有时候我必须比其他人多工作一点。但同样，为了抵消这些繁忙的时期，也有间歇期。在这些平静期间，我可以重新激发自己的活力，并赶上一些不太重要的事情，为下一个繁忙的周期做准备。多年来，学习和理解它帮助我处理了它。我不得不在这个问题上指导许多年轻的专业人​​士，这样他们就可以学习如何在上升期应对压力和时间管理。看到他们度过高努力期，看到他们在平静期放松下来，为下一次大努力做好准备，这是一件很值得的事情。

I have to prioritise in order to manage the demands on my time; I have to say no to some things or delegate what I can. I also know that there are times in a release cycle that will require overtime. It is cyclical and part of the job and if you understand that it will all eventually come out in the wash; you can manage it. My family has come to learn this important concept and knows that there will be times when I have to work a bit more than others. But again, to counteract these busy times, there are also lulls. During these lulls I can re-energise myself and catch-up on some of the less critical things in preparation for the next busy cycle. Learning this and understanding it has helped me to deal with it over the years. I have had to mentor many young professionals on this very subject so they can learn how to deal with the stresses and time management during the upswings. It is rewarding to see them get through the high-effort times and see them relax during the lulls to get ready for the next big push.

您如何在编写代码和处理其他问题之间取得适当的平衡？

How do you strike the right balance between writing code and dealing with other issues?

正如我上面提到的，我目前的角色导致代码编写有限，很难亲自处理。不过，我正在尽我所能回到它。这场斗争的一部分是将我的团队带到一个他们对应用程序有更多了解并对自己的决策能力更有信心的地方。这必须是我推动的一种权衡，其中一部分是我放弃了对他们的一些控制——我相信他们会按照预期去做。在这方面，我正试图抓住机会进行教学和授权。这是一个漫长的过程，不会立即让我重新开始编写代码——但希望从长远来看，它会让我和团队受益。

As I mentioned above, my current role has resulted in limited code writing and it is been difficult to deal with personally. I am working on doing all I can to get back to it though. Part of this struggle has been bringing my team to a place where they have more knowledge about the application and more confidence in their own decision-making abilities. It has to be a trade-off that I drive through and part of it is me letting go of some of that control to them – my confidence in them to do what’s expected. In that respect, I am trying to take opportunities to teach as well as to delegate. It is a long process and one that won’t immediately result in me getting back to writing code – but hopefully in the long run, it will benefit me as well as the team.

Christy 的关键问题：作为 Tech Lead，您认为您对团队的最大贡献是什么？

Christy’s key question: What do you think are your greatest contributions to the team as a Tech Lead?

我对这个团队最大的贡献是我的应用专业知识（我只知道所有的骨头都埋在哪里）和我的一般开发和解决问题的诀窍！

My greatest contributions to this team are my application expertise (I just know where all the bones are buried) and my general development and problem resolution know-how!

我被要求为我的团队提供一个关于我如何解决问题的教学课程，特别是针对最近出现的几个问题。我想认为我在这个主题上的一些专业知识是知道如何找到问题的根源，而不是专门针对这个应用程序。正如我之前提到的，我真的很擅长这部分工作——无论是学习的还是天生的——可能两者兼而有之。我被要求这样做的原因之一是，我花了 30 分钟来解决一个问题，而这个问题是团队中许多成员整整工作了两天都没有解决的。我怎么能在这么短的时间内找到并解决问题？尤其是很久没有接触代码了？我整理了一份通用文件，概述了我的思考过程以及我在遇到类似问题时问自己的问题，然后与团队分享。

I have been asked to provide a teaching session to my team on how I go about resolving issues and specifically geared towards a couple of issues that came up recently. I would like to think that some of my expertise on this subject is knowing how to go about getting to the bottom of an issue and not tied specifically to this application. As I mentioned before, I am really good at this part of the job – whether it is learned or natural – probably a little bit of both. One of the reasons I was asked to do this was that it took me 30 minutes to solve an issue that numerous members of the team had worked on for two whole days without resolving. How was it that I could find and fix the issue in such a short amount of time? Especially not having been in the code for a long while? I put together a general document outlining my thought process and the questions I ask myself when faced with an issue like the one we had and then shared that with the team.

应用专业知识只是伴随着代码中的时间以及花费时间和精力将其应用到内存中而来。然而，我也怀疑许多开发人员不会费心去解决问题、功能区域或应用程序的症结所在，而只是掩盖表面，关注它是“什么”。我认为我经常想知道问题发生的根本原因这一事实帮助我成为了技术主管，因为我更有能力回答我们是否可以做某事或如果可能会发生什么等难题我们做到了。如果你不看“为什么”和“什么”，你就无法真正达到那种理解水平。同样的方法也适用于我之前提到的问题解决和我分享的部分内容。

The application expertise just comes with time in the code and taking the time and effort to apply it to memory. However, I also suspect that many developers don’t bother to get to the crux of a problem, functional area, or application and simply gloss over the surface, focusing on “what” it is. I think the fact that I often want to know the root cause of why a problem has occurred has helped me become a Tech Lead, as I am more able to answer the difficult questions of whether we can do something or what is likely to happen if we do it. If you don’t look at “why” as well as “what”, you cannot really get to that level of understanding. This same approach is also applicable to the problem-solving I mentioned before and part of what I shared.

克里斯蒂的背景故事

Christy’s background story

Christy 在分析、编码和解决问题方面的技能使她非常适合 Tech Lead 的角色，她在过去 27 年中一直在财富 500 强公司担任该职位。

Christy’s skills in analysis, code, and resolving problems made her a perfect fit for the Tech Lead role, which she has played with Fortune 500 companies for the past 27 years.

优先处理技术任务——Chris Close

Prioritising Tech Tasks – Chris Close

Tech Lead 应该关注什么？为什么？

What should a Tech Lead focus on and why?

在 Tech Lead 角色中要考虑的最重要的事情是何时执行架构修改/重构具有最大的业务和技术意义。如果这些重要任务没有在正确的时间完成，解决方案就会变得一团糟。但如果你做的太多，企业可能不会“看到”任何实际好处。

The most important thing to consider in a Tech Lead role is when it makes the most business and technical sense to perform architectural modifications/refactoring. If these important tasks aren’t done at the right time, the solution will spiral into a mess. But if you do too much of it, the business might not “see” any actual benefits.

作为 Tech Lead，您遇到的最大挑战是什么？

What has been your biggest challenge as a Tech Lead?

我很难尝试将技术任务安排到与业务的冲刺中。在尝试自己与产品负责人解决问题后，我不得不让更高层的经理同意这项工作对最终产品有益，然后将工作安排在多个冲刺/迭代中。

I had a tough time attempting to schedule in tech tasks into a sprint with the business. After trying to resolve the situation myself with the product owner, I had to get managers higher up to agree that the work was beneficial to the end product and then had the work scheduled in over several sprints/iterations.

有什么时间管理技巧吗？

Any time-management tips?

确保你有一支优秀的团队，你可以将工作任务交给他们。这意味着您可以放心地将时间用于与调查或分析相关的高优先级任务/问题。当然，您仍然需要与团队一起检查这些任务的进展情况并在必要时提供帮助，但这不需要大量、连续的时间块。

Ensure you have a good team of people that you can hand over work tasks to. This means that you can feel confident in using your time for high-priority tasks/issues relating to investigations or analysis. Of course, you still need to check in with the team on how these tasks are progressing and provide assistance where necessary, but it doesn’t require large, continuous blocks of time.

另一个好主意是让所有正在进行的工作对您和团队可见。这样，任何重要的事情都会在每日站立会议中讨论。然后你也可以更好地利用他们的时间，因为他们知道这些任务的进展。

Another good idea is to keep all work in progress visible to you and the team. This way anything important will be talked about in daily stand-up meetings. You are then also in a better position to leverage their time later on as they are aware of the progress on these tasks.

您如何在编写代码和处理其他问题之间取得适当的平衡？

How do you strike the right balance between writing code and dealing with other issues?

由于解决突然出现的问题而中断，这可能很困难。这可以通过结对编写代码来解决，这样你就可以处理几分钟的问题或简短的对话，然后回到代码中，同时仍然保持手头编码任务的动力。

This can be difficult due to interruptions to address issues that crop up. This can be solved by pairing for code-writing, so that you can deal with issues or short conversations for a few minutes and return to the code while still maintaining momentum in the coding task at hand.

您需要保持平衡，同时仍将手放在代码中，以便以后可以根据已创建的代码的基础结构做出正确的决策。

You need to have a balance and still keep your hands in the code so that you can make good decisions later on based on the infrastructure of the code that has been created.

Chris 的关键问题：您如何确信计划的工作已准备好由您团队中的开发人员完成？

Chris’s key question: How do you feel confident that the work scheduled is ready to be done by developers in your team?

虽然在故事开始之前进行大量的前期技术分析在效率方面可能没有意义（因为故事可能永远不会开始），但重要的是任何开发人员都可以充分理解任务即将开始工作。

While it may not make sense in terms of efficiency to undertake a large amount of up-front technical analysis before a story is started (because a story may never be started), it is important that a task can be fully understood by any developer that is about to start work on it.

有几种策略可以实现这一点：

There are a couple of strategies to achieve this:

• 确保团队在计划任务时了解任务的广度和深度。故事的任何假设都应包含在故事的细节中，但可以根据技术常识和业务需求灵活调整——当然，所有各方都同意。
• Ensure the team is aware of the breadth and depth of a task while it is being planned. Any assumptions for the stories should be included in the detail of the story, but can be flexible, based on technical common sense and business needs - all parties being in agreement, of course.
• 当一项任务开始时，举行白板会议，让团队集思广益，讨论不同的想法和解决方案，以便每个人都知道如何推进工作。
• When a task is started, hold a whiteboard session where the team brainstorms different ideas and solutions so that everyone knows how to move forward with the work.

克里斯的背景故事

Chris’s background story

Chris 从事软件开发已有 12 年，并于 2007 年首次担任技术主管。他在过去一年担任目前的技术主管一职，他的大部分工作都与 .Net Web 技术（如 MVC4）有关。

Chris has been working in software development for 12 years and first acted as a Tech Lead in 2007. He moved into his current Tech Lead role in the past year and most of his work is with .Net web technologies such as MVC4.

将业务与技术联系起来

Bridging the Business with Tech

当开发人员成为 Tech Lead 时，他们与业务其他部分的关系会变得更加牢固。本节中的回答概述了为什么这些关系很重要，并描述了关系的性质如何变化。

When a developer becomes a Tech Lead, their relationship with other parts of the business becomes stronger. The responses in this section outline why those relationships are important and describe how the nature of the relationship changes.

建立信任

Building Trust

作为 Tech Lead，您需要花更多时间与非技术利益相关者打交道，这是建立信任的好机会。非技术利益相关者对时间的去向持怀疑态度，因为软件涉及的内容太多而无形。技术负责人必须不断管理这样一种看法，即太多时间花在可能没有任何明显可见投资回报的活动上。我发现扎根于更传统零售背景的公司更容易受到这种看法的影响。

As a Tech Lead, you spend more time with non-technical stakeholders and this is a good opportunity to build trust. Non-technical stakeholders are suspicious of where time goes, because software involves so much that is intangible. The Tech Lead must constantly manage the perception that too much time is being spent on activities that may not have any obvious visible return on investment. I have found that companies with roots in a more traditional retail background are more susceptible to this perception.

Tech Lead 的技术强调了花时间处理技术任务的必要性，以及获得非技术人员的信任如何让开发团队有更多的自由去做他们认为必要的事情。以下引述是建立信任的最佳方式之一：

The Tech of a Tech Lead highlights the need to spend time working on technical tasks and how gaining the trust of non-technical people gives the development team more freedom to do what they think necessary. One of the best ways of building trust is best summarised by the following quote:

培养与非技术利益相关者的信任需要时间。Tech Leads 找到了一种方法来平衡团队和团队外人员之间的时间。找到这种平衡是一场斗争。一些受访者讨论了以过多的技术细节结束是多么容易。

Nurturing trust with non-technical stakeholders takes time. Tech Leads find a way to balance time between the team and those that sit outside the team. Finding this balance is a struggle; some of those interviewed discussed how easy it was to end up in too much technical detail.

找时间学习技术

Finding Time for Technology

技术负责人管理技术风险并支持在质量上投入时间的需求，但这只能在其他方的信任下才能完成。找到足够的时间是一个持续的挑战。当团队在没有交付价值的情况下花费太多时间在软件质量上时，您就有可能破坏您建立的信任。

A Tech Lead manages technical risk and champions the need for time invested in quality, but this can only be done with trust from other parties. Finding enough time is a constant challenge. When the team spends too much time on software quality without delivering value, you risk breaking the trust you have built.

幸运的是，将时间花在质量问题上会对最终用户或业务产生直接的积极影响，例如，通过让用户体验更好更快，或者减少对帮助和协助的请求。

Fortunately, spending time on quality issues has a direct positive impact on end-users or the business, by making the user experience better and faster, for example, or resulting in fewer requests for help and assistance.

花在软件质量上的时间太少会导致内部质量问题，并迅速转化为可见的外部质量问题。管理技术债务是 Tech Lead 的一项关键技能。

Spending too little time on software quality leads to internal quality issues and quickly turns into visible external quality issues. Managing the Technical Debt is a key skill for the Tech Lead.

每个开发人员对可接受的质量都有自己的看法。有些人想完善他们的代码，花更多的时间在上面；其他人则采取砍刀和砍刀的方法，有利于快速反馈，但会导致无法管理的混乱。技术负责人负有最终责任，并且必须根据交付的价值监控何时何地采用每种方法。

Every developer has their own perception of acceptable quality. Some want to perfect their code, spending significantly more time over it; others take a hack-and-slash approach that favours fast feedback but results in an unmanageable mess. The Tech Lead is ultimately accountable and must monitor where and when to take each approach based on value being delivered.

使技术解决方案易于理解

Making Technology Solutions Easy to Understand

开发人员被定型为缺乏沟通技巧。您可能认识到这些特征： - 他们没完没了地谈论技术细节，不会停下来问对方问题，甚至不会确保他们在同一页上；他们假设其他各方知道他们使用的所有术语和更广泛的背景。

Developers are stereotyped as having poor communication skills. You probably recognise the characteristics: - they go on endlessly about technical detail, not pausing to ask questions of the other person or even ensuring they are on the same page; they assume that the other parties know all the terms they are using and the broader context.

Tech Lead 必须培养必要的技能，帮助非技术人员理解技术问题并在必要时与技术问题相关联。他们利用简单图表、协作白板会话、隐喻和简单、清晰的语言等交流工具，使用最少（或者更好的是，不使用）首字母缩略词和技术术语。他们设身处地为非技术人员设身处地，预测技术细节何时可能很重要，以一种不具威胁性的方式介绍技术术语，不会让对方感到愚蠢。他们谨慎地进行教育，因为他们认识到有些人不想或不需要了解一定程度的技术细节。

A Tech Lead has to develop the essential skill of helping non-technical people understand and relate to the technical issues when necessary. They draw upon the communication tools of simple diagrams, collaborative whiteboard sessions, metaphors and simple, clear language with minimal (or better yet, non-existent) use of acronyms and technical terms. They put themselves into the shoes of non-technical people and anticipate when a technical detail might be important, introducing technical terminology in a non-threatening manner that does not leave the other person feeling stupid. They educate with care because they recognise that some people do not want, or need, to know a certain level of technical detail.

Tech Lead 始终意识到并非所有问题都可以或应该通过技术解决方案来解决。Tech Lead 与非技术人员建立信任。只有获得信任后，Tech Lead 才能更坦诚地描述特定解决方案的失败之处，描述为什么提出的一种技术方案可能无法解决问题。他们还努力将必要的沟通技巧传授给技术团队的其他成员，这样企业就不会依赖一个人。当他们目睹非技术人员被技术术语淹没时，他们会向开发人员提供反馈，并鼓励使用白板来可视化并发现技术和非技术成员之间的理解差异。

The Tech Lead is constantly aware that not all problems can, or should be solved by technical solutions. The Tech Lead builds trust with non-technical people. Only after gaining trust can a Tech Lead describe the downfalls of a particular solution more openly, describing why one technical solution proposed may fail to solve the problem. They also work to pass on the necessary communication skills to other members of the technical team so the business does not rely on a single person. They provide feedback to developers when they witness a non-technical person being overwhelmed by technical jargon and encourage the use of whiteboards to visualise and find differences in understanding between technical and non-technical members.

影响规划

Influencing Planning

组织在预算和规划周期中寻求 Tech Lead 的意见。团队的零参与通常会导致过度承诺和技术风险被忽视。建立在信任基础上的牢固关系为 Tech Lead 创造了影响规划过程的机会。

Organisations look to the Tech Lead for input during budgeting and planning cycles. Zero involvement from the team often leads to over-commitment and technical risks being overlooked. A strong relationship built on trust creates opportunity for the Tech Lead to influence the planning process.

在此规划过程中，技术负责人会发现商机，以低投入使用技术，或提高技术风险高领域的可见性。技术负责人注意不要过度承诺，​​因为他们知道自己并非无所不知；如果计划出错，在没有团队参与的情况下承诺团队会在未来造成紧张。

During this planning process, the Tech Lead spots business opportunities to use technology based on low effort, or to bring visibility to high areas of technical risk. The Tech Lead is careful not to over-commit, as they are aware they do not know everything; committing the team without its involvement creates future tension if the plan goes wrong.

承诺不足，交付过度——汤姆·彼得斯，来自“追求卓越”

Under promise and over deliver - Tom Peters, from “In Search of Excellence”

Tech Lead 对规划过程的影响可能很大，但您必须注意不要在上面花费太多时间。参与规划流程会占用 Tech Lead 在团队和代码库上花费的时间。技术主管花在团队和代码之外的时间越多，他们就越有可能低估复杂性或在不知不觉中承担额外的风险。

The Tech Lead’s influence over the planning process is potentially great, but you must beware of spending too much time on it. Involvement in planning processes eats into time a Tech Lead spends with the team and the codebase. The more time a Tech Lead spends away from the team and the code, the more likely they too will underestimate complexity or unknowingly take on additional risk.

参与规划过程可以让 Tech Lead 更深入地了解即将到来的领域。有关未来计划的知识有助于做出更好的决策，尤其是在代码库中的假设情景之间进行仲裁时。

Involvement in the planning process gives the Tech Lead greater insight into upcoming areas. Knowledge about plans for the future makes for better decision-making, particularly when arbitrating between what-if scenarios in the codebase.

支持业务需求

Championing Business Needs

随着您花更多的时间与业务密切相关，技术主管会意识到对业务真正重要的东西。技术负责人利用这些知识让团队更加了解他们的操作环境。技术负责人阐明当前目标并提醒团队他们的软件如何使业务朝着目标前进。

As you spend more time closer to the business, the Tech Lead appreciates what is truly important to the business. The Tech Lead uses this knowledge to make the team more aware of their operating context. The Tech Lead clarifies the current goal and reminds the team how their software moves the business towards the goal.

更清楚地了解真正的目标有助于开发人员做出更好的选择。例如，一个设计可能需要最终用户进行更多的手动处理，但软件功能可能会迎合边缘情况，开发团队投入的时间回报率可能不够高，并且可能使更改业务流程变得困难未来。

A clearer understanding of the real goal helps developers make better choices. For example, one design may require more manual processing by end-users, but the software function may cater for an edge case and the return on the time invested by the development team may not be high enough and could make changing business processes difficult in the future.

相反，如果软件中的错误威胁到企业的基本现金流，无论多么罕见，开发团队都可能会花费额外的时间来构建高质量的设计。

In contrast, if an error in the software threatens essential cashflow for the business, regardless of how rare, the development team might spend additional time building a quality design.

技术选择很少存在于业务环境之外，在业务环境中，时间不断地与更好的回报希望进行权衡。技术主管在团队中建立超越键盘和正在构建的系统的意识。

Technical choices rarely exist outside of a business context where time is constantly traded off with the hopes of better returns. The Tech Lead builds awareness in the team that goes beyond the keyboard and the systems being built.

大局——卢卡·格鲁拉

The Big Picture – Luca Grulla

Tech Lead 应该关注什么？为什么？

What should a Tech Lead focus on and why?

Tech Lead 必须清楚地掌握项目的大局。他们需要了解预期的业务目标是什么，并帮助团队将该想法转化为系统。

A Tech Lead has to clearly grasp the big picture of the project. They need to understand what the expected business goal is and help a team to transform that idea into a system.

为了实现这一目标，他们必须在满足业务需求的交付速度与保持能够实现长期回报的整体技术质量之间找到微妙的平衡。

To achieve the goal they have to find the delicate balance between a delivery pace that satisfies business needs and maintain an overall technical quality that enables long-term returns.

作为 Tech Lead，您遇到的最大挑战是什么？

What has been your biggest challenge as a Tech Lead?

我发现最大的挑战是协调和协调业务需求与技术需求。

I find the biggest challenge is in co-ordinating and mediating business needs with technical needs.

几年前，我加入了一个努力赶上固定期限的项目。由于业务的特殊性质，最后期限很严格，错过它会严重影响项目的投资回报。我看到了不同层次的问题：

A few years ago, I joined a project struggling to meet a fixed deadline. The deadline was strict due to the specific nature of the business and missing it would have significantly affected the project’s return on investment. I saw problems at different levels:

• 一个经常改变主意的产品负责人
• A product owner that often changed their mind
• 一个团队经常被额外的功能打断和转移注意力
• A team constantly interrupted and sidetracked with extra features
• 一个在截止日期前努力奋斗的团队
• A team struggling with motivation to meet the deadline

在这方面，我重点关注了几个方面：

In this context, I focused on several areas:

• 重组团队以澄清最后期限的严重影响，并确保我们付出额外的努力。
• Shaking up the team to clarify the serious implications of the deadline and ensure we put in extra effort.
• 与开发人员一起确定系统中造成最大痛苦的部分，并计划如何在交付计划功能的同时改进或重写它们。
• Working with developers to identify the parts of the system causing the most pain, and planning how to improve or rewrite them whilst delivering the planned features.
• 监控额外的功能以避免不必要的范围，并与企业所有者密切合作以确定那些增加业务价值并且对截止日期至关重要的功能。
• Monitoring the extra features to avoid unnecessary scope, and working closely with the business owner to identify those features that added business value and were essential to deadline.

有什么时间管理技巧吗？

Any time-management tips?

尽管 Tech Lead 的时间很宝贵，但重要的是让任何需要交谈的人都能参与进来。我试图创造一个环境，让人们知道我在那里提供帮助，无论是从业务角度还是从技术角度。我鼓励人们来和我自由交谈。如果我不能立即回复，我会尽快回复他们。

Although Tech Lead time is precious, it is important to be available to anyone who needs to talk. I try to create an environment where people know I am there to help, both from a business and from a technical perspective. I encourage people to come and talk freely to me. If I cannot respond immediately, I try to get back to them as soon as possible.

我尽量减少正式会议的时间。尽管我收到很多会议邀请，但我从不拒绝。如果我觉得我不会为会议增加多少价值，我会向组织者询问会议的目标和他们对我的期望。如果他们证实了我的怀疑，或者我对内容不感兴趣，那么我会问是否可以跳过它。

I try to minimise time in formal meetings. Although I am sent many meeting invitations, I never decline them. If I do not feel I would add much value to the meeting, I ask the organiser about the goal of the meeting and their expectations of me. If they confirm my suspicion, or I am not interested in the content, then I ask if it is okay to skip it.

与正式会议相比，我更喜欢其他人可以随意与我交谈的环境。以不太正式的方式处理决策通常更节省时间。显然，这并不总是可能的，因为担任不同角色的人有不同的期望，在这种情况下，我会尝试提前计划，这样我就不必一直跳入事情中。

Instead of formal meetings, I prefer an environment where others feel comfortable talking to me casually. Handling decisions in a less formal way is often more time effective. Obviously, this is not always possible because people in different roles have different expectations, in which case I try to plan ahead so that I don’t have to keep jumping into things.

您如何在编写代码和处理其他问题之间取得适当的平衡？

How do you strike the right balance between writing code and dealing with other issues?

这取决于项目的需要；Tech Lead 有时需要稍微少动手。Tech Leads 需要培养一种“第六感”技能，以理解在特定情况下什么是高优先级的。有时你觉得项目需要更多的业务支持；有时您必须意识到团队正在努力解决技术问题，而您可以通过直接参与来提供帮助。棘手的部分是不要让这两个方面中的任何一个占用你 100% 的时间太久。我发现在一定时间内大量参与问题的业务方面特别容易忘记技术。

It depends on the needs of the project; a Tech Lead needs to be slightly less hands-on sometimes. Tech Leads need to develop a “sixth sense” skill of understanding what is high priority given the context. Sometimes you feel the project needs more support from a business perspective; sometimes you have to appreciate that the team is wrestling with technical issues where you can help by being directly involved. The tricky part is not letting one of the two aspects take 100 per cent of your time for too long. I have found it is particularly easy to become heavily involved in the business side of the problems for a certain amount of time to lose track of the technology.

在某些时期，我意识到我无法为整体技术交付做出太多贡献，因此我会努力了解情况并专注于帮助团队专注于我们的整体架构。当我作为 Tech Lead 的重点是向业务方面提供建议和技术支持时，我会不断浏览代码库以了解总体方向。我与团队的其他成员讨论他们试图解决的日常问题。午餐前后的非正式聊天对此非常有用。我密切关注墙上的故事流程，以了解系统如何发展的心理地图。如果我觉得我们正在迷失方向，我会尝试提醒团队整体计划以及预期的商业价值。我可能会在站立会议之后这样做，或者在一天结束时与所有技术人员即兴聚会。

There are periods where I’m aware I can’t contribute much to the overall technical delivery and I try to stay in the loop and focus on helping the team concentrate on our overall architecture. When my focus as Tech Lead is giving input to the business side, such as advice and technical support, I keep browsing the codebase to understand the overall direction. I talk with the rest of the team about the daily problems they are trying to solve. Informal chats to and from lunch are great for this. I keep a close eye on the story flow on the wall to have a mental map of how the system is growing. If I feel we are losing direction, I try to remind the team of the overall plan and what the expected business value is. I might do this following the stand-up, or with an impromptu gathering with all the technical people at the end of the day. If another team member is strongly advocating a change of direction, I might sit with them to understand their reasoning and to find out if they have discovered a better direction than the one currently planned.

我尽量留出专门的时间，这样我就可以不受干扰地编码。对我来说，理想是半天。有时我预定超时。如果我在编码时遇到了一个不紧急的问题，我会提出在当天晚些时候解决它。人们可以接受，“我们可以稍后再谈这个吗？” 只要我提供替代时间就可以回复他们。确保您在同意后确实回复了他们，并且不要在最后一刻再次推迟，因为您将开始失去对团队的信任。这种方法使我能够在开始结对时专注于编码，但仍然可以满足其他人的需求。

I try to set aside dedicated time so that I can code without interruptions. An ideal, for me, is half a day. Sometimes I book time out. If I’m approached with a non-urgent issue while I am coding, I offer to address it later in the day. People are okay with, “Can we talk about this later?” as long as I offer an alternative time get back to them. Make sure you actually do get back to them when you agreed and don’t postpone again at the last minute as you will start to lose trust with your team. This approach gives me the ability to focus on coding when I start pairing, but still makes me available for others’ needs.

Luca 的关键问题：Tech Lead 应该学习的最紧迫的教训是什么？

Luca’s key question: What is the most urgent lesson a Tech Lead should learn?

作为 Tech Lead，您将被拉向许多不同的方向。你会被整体架构所占据；为业务提供投入和支持；讨论和规划生产路径，有时通过调入（或调出）人员来重塑团队。有这么多不同的职责，你需要接受你无法影响系统的每个部分。在这个角色中，您可以拥有最终决定权，但要明智地使用它。如果你看到一些你不同意的事情，问问自己，“它是否危及项目的整体成功？还是只是我个人口味的问题？”

As Tech Lead, you will be pulled in many different directions. You will be occupied with the overall architecture; providing input to and supporting the business; discussing and planning for the path to production, and sometimes reshaping the team by rolling people in (or out). With so many different responsibilities, you need to accept that you will not be able to influence every part of the system. In this role, you can have the final word, but use it wisely. If you see something you do not agree with, ask yourself, “Is it jeopardising the overall success of the project? Or is just a matter of my personal taste?”

你的角色应该是关注可能导致项目失败的技术问题。您必须学会识别并接受可行的替代解决方案——而不仅仅是您自己的解决方案，尤其是当您在相同的位置上可能不会这样做时。与团队合作开发替代解决方案可以吸引他们并产生强烈的主人翁意识。自己做所有事情会带来成为瓶颈和单点故障的风险。

Your role should be to keep on top of technical issues that might lead to a project failing. You must learn to recognise and accept feasible alternative solutions - not just your own, and particularly if it is not what you might do if in the same position. Working with the team to develop alternative solutions engages them and creates a strong sense of ownership. Doing it all yourself introduces the risk of you becoming the bottleneck and a single point of failure.

卢卡的背景故事

Luca’s background story

Luca 在其从事技术工作的 12 年中领导了大约六个团队。他目前的职位是uSwitch的高级软件工程师。在此之前，Luca 在 ThoughtWorks 担任了四年技术主管。

Luca has lead about six teams in his 12 years working with technology. His current role is acting as a Senior Software Engineer at uSwitch. Before that Luca spent four years at ThoughtWorks as a Tech Lead.

使技术与业务保持一致——Robert Annett

Align Technology with Business – Robert Annett

Tech Lead 应该关注什么？为什么？

What should a Tech Lead focus on and why?

Tech Lead 使团队保持在交付业务需求的轨道上，同时确保这些需求在非功能需求之内。

The Tech Lead keeps the team on track to deliver the business requirements, while making sure these are within the non-functional requirements.

开发团队很容易忽视他们的雇主真正想要什么，而是专注于他们自己的目标。例如，他们更担心使用很酷的技术或达到任意单元测试覆盖率指标，而不是最终用户实际需要什么。

It is easy for a development team to lose sight of what their employer actually wants and instead focus on their own goals. For example, they worry more about using cool technologies or hitting an arbitrary unit test coverage metric rather than what the end user actually needs.

作为 Tech Lead，您遇到的最大挑战是什么？

What has been your biggest challenge as a Tech Lead?

我最具挑战性的情况是主要最终用户希望项目失败。这比大多数 IT 工作者意识到的更为普遍；大多数人不喜欢变化，更换 IT 系统可能会危及当前用户的工作。这通常会导致用户故意隐瞒信息并反对合理的功能。

My most challenging situation was one where the main end user wanted the project to fail. This is more common than most IT workers realise; most people don’t like change and a replacement IT system may endanger the current user’s job. This often leads to users deliberately withholding information and opposing reasonable functionality.

我是怎么处理的？我承认：很糟糕。开发人员倾向于寻找技术解决方案，对于最终用户投掷的每一枚“手榴弹”，我都试图将其作为技术问题来解决。这导致艰苦的工作和不断的变化。归根结底是政治问题，解决办法也是政治性的；例如，我本可以尝试获得管理层的支持以实施变革并停止任何破坏活动。

How did I handle it? I admit: badly. Developers tend to look for technical solutions and for every “hand grenade” thrown by the end user, I tried to work around it as a technical problem. This leads to hard work and constant change. Ultimately it is a political issue and the solution is also political; for example, I could have tried to get buy-in from management to implement the change and stop any sabotage.

有什么时间管理技巧吗？

Any time-management tips?

计划并关注大局。很容易陷入技术问题的细枝末节。您需要知道何时“宣布胜利”解决问题并继续前进。

Plan and keep an eye on the big picture. It is easy to get bogged down in the minutiae of a technical issue. You need to know when to ‘declare victory’ over a problem and move on.

您如何在编写代码和处理其他问题之间取得适当的平衡？

How do you strike the right balance between writing code and dealing with other issues?

如果您的责任超出了编写代码的范围，则它们会优先考虑，您需要确保您的代码编写任务不在当前的关键路径上。这是为了避免在您暂时无法处理时阻碍他人的进度。您还需要确保您不是唯一出于同样原因了解特定业务领域或技术的人。与团队的初级成员结对（无论他们碰巧在做什么）都很好，与关键路径上的任何人结对也是如此。

If you have responsibilities beyond writing code, they take priority and you need to ensure your code-writing tasks are not on the current critical path. This is to avoid blocking others’ progress if you cannot work on it for a while. You also need to make sure you aren’t the only person who knows a particular business area or technology for the same reason. Pairing with junior members of the team (on whatever they happen to be working) is good, as is pairing with anyone on the critical path.

罗伯特的关键问题：“你如何处理团队内部的冲突？”

Robert’s key question: “How do you deal with conflicts within the team?”

对于技术背景的人来说，这些可能很难。关键是要保持专业，不要情绪化。避免在生气时发送电子邮件。要直接和诚实。保持冷静、超然和调解，但一旦你听取了所有人的意见，你就必须做出决定并坚持下去。偶尔让大家有一次胜利也是好的。例如，如果有人真的想为 wiki 使用某个模板，就让他们使用吧。

These can be difficult for someone from a technical background. The key is to remain professional and not become emotional. Avoid sending email while you are annoyed. Be direct and honest. Stay calm, detached and mediate, but once you’ve listened to everyone then you must make a decision and stick to it. It is also good to let everyone have a victory once in a while. For example, if someone really wants to use a certain template for the wiki, let them.

罗伯特的背景故事

Robert’s background story

Robert 自 1995 年以来一直从事 IT 工作。在“大数据”一词流行之前，他的大部分工作都是处理具有大量数据集的后端系统。在那段时间里，他扮演过各种角色，包括多个团队的技术主管。他最近的经历是在一家金融机构担任“前台”职位，他发现该职位更具反应性。

Robert has worked in IT since 1995. Most of his work has been with backend systems with large sets of data before the term “big data” became trendy. In that time he has played various roles, including a Tech Lead for a number of teams. His most recent experience was working in a “front office” role for a financial institute where he finds the role more reactive.

描绘未来——杰森·丹尼斯

Mapping the Future – Jason Dennis

Tech Lead 应该关注什么？为什么？

What should a Tech Lead focus on and why?

我担心正在使用的技术以及我们未来应该使用什么：有没有更好的方法来做我们需要做的事情？我还担心团队正在生成的代码是否遵循我的设计和编码指南；有时我对此有点迂腐。

I worry about the technology being used and what we should be using for the future: is there a better way to do what we need to do? I also worry whether the code being produced by the team follows my design and coding guidelines; I am a bit pedantic about that sometimes.

我专注于提高绩效；我要快点；我想要 Google 的速度，因为客户不会等待页面加载。我还想专注于提高团队技能和开发技能，让人们更快地解决代码问题，这样我们就可以专注于更大的问题。

I focus on improving performance; I want it quicker; I want Google speed, because customers won’t wait for the page to load. I also want to focus on improving the team skills and developing skills that get people moving through the code issues faster so we can focus on bigger issues.

作为 Tech Lead，您遇到的最大挑战是什么？

What has been your biggest challenge as a Tech Lead?

最近一次是平台升级，我们在项目中使用了外部供应商，但他们不了解我们的业务模型，因此做出了我们永远无法支持的假设。一个例子是将管理和前端网站混合到一个站点中：我不得不将它们分开，因为将管理和网站混合会带来各种各样的问题，其中最重要的是供应商糟糕的设计选择。

The most recent was a platform upgrade where we used an outside vendor for the project, but they didn’t understand our business model and so made assumptions we could never support. One instance was the co-mingling of the admin and front-facing website into one site: I had to split them because mixing the admin with the website would bring all kinds of problems, not least of which were poor design choices by the vendor.

尽管时间非常紧迫，而且人们说不能或不应该这样做，但我还是决定这样做，因为这对公司来说是最好的。我还设计了整个解决方案，使其符合最佳实践。

Even though time was extremely tight and people said it couldn’t or shouldn’t be done, I decided to do it because it was best for the company. I also designed the entire solution so it fitted best practices.

有什么时间管理技巧吗？

Any time-management tips?

我尽量在收到电子邮件时回复他们，这样人们就不会发送更多电子邮件来询问我为什么没有回复他们。如果需要，我也会尝试划出固定的时间段来专注于一项任务，但如果可能的话，我会尽量避免这样做。

I try to answer emails as they come so people don’t send more emails asking why I haven’t answered them. I also try and carve out set periods of time to focus on a task if I need to, but I try to avoid doing this if possible.

对于项目，我会尽力做出正确的估计，假设我不会一直在项目上工作，而是会有其他事情要处理。

For projects I try my best to estimate correctly based on the assumption that I won’t be working on the project all the time but will have other things to deal with.

您如何在编写代码和处理其他问题之间取得适当的平衡？

How do you strike the right balance between writing code and dealing with other issues?

平衡是很棘手的，有时你只需要顺应当时发生的事情而不是你想做的事情。

Balance is tricky and sometimes you just have to go with the flow of what is happening at the time rather than what you would like to be doing.

Jason 的关键问题：我如何成为领导者？

Jason’s key question: How do I become a leader?

学习和成长。你需要尽你所能去学习，永远不要坐以待毙，因为你的工作已经够多了；继续吸收有关新技术和新最佳实践的知识。帮助他人在他们的角色中成长，让您成为领导者。

Learn and grow. You need to learn all you can, never sit still because you have enough to do in the job; keep on sucking down knowledge about new technologies and new best practices. Help others to grow in their role so you shine as a leader.

杰森的背景故事

Jason’s background story

Jason 自 1995 年以来一直从事此工作，自 1982 年以来一直从事计算机工作。在大约九年的时间里，他在不同的组织中多次担任本地和远程团队的技术主管角色。他的兴趣各不相同，但在工作允许的情况下，他喜欢改造自己的房子，还喜欢阅读和了解不同的技术，了解技术领域的最新动态。

Jason has been doing this since 1995 and has been around computers since 1982. He has played the Tech Lead role a few times at different organisations with both local and remote teams over the course of about nine years. His interests are varied, but when work allows he likes to work on remodelling his house as well as reading and keeping up with different technologies and seeing what is out there in the realms of technology.

在业务中找到平衡——Cory Foy

Finding Balance with the Business – Cory Foy

Tech Lead 应该关注什么？为什么？

What should a Tech Lead focus on and why?

我认为 Tech Lead 应该关注的最重要的事情是快速交付客户价值和满足架构计划需求之间的平衡。很多时候，客户向我们询问他们不知道的事情。在我们交付一些东西之前，他们无法给我们有意义的反馈，所以我们在得到反馈之前等待的时间越长，我们可能犯的错误就越大。但这必须与构建高质量系统的架构愿景相平衡。诀窍是通过构建可能可交付的小部分价值来实现这一愿景。

I think the most important thing a Tech Lead should focus on is the balance between delivering customer value rapidly, and meeting the needs of the architectural plan. Too often, customers are asking us for things they don’t know they don’t know. They won’t be able to give us meaningful feedback until we have delivered something, so the longer we wait before getting that feedback, the more wrong we could be. But that has to be balanced with a vision of the architecture to build a high-quality system. The trick is to deliver that vision by building small slices of value that are potentially shippable.

作为 Tech Lead，您遇到的最大挑战是什么？

What has been your biggest challenge as a Tech Lead?

人与沟通；我认为对于任何 Tech Lead 来说，人的挑战几乎胜过每一项技术挑战。当我在微软工作时，我们被派往客户站点，那里的系统出现故障，公司损失了大量资金。他们为此训练我们的方式是让我们参加为期三周的软技能新兵训练营。出于这个原因，我建议 Tech Leads 着眼于软技能方面，以及像关键对话这样的书：赌注高时的谈话工具，如何每次争论和获胜：在家里，在工作中，在法庭上，无处不在，每天和闭门造车：伟大管理的秘密。

People and communication; I think for any Tech Lead, the people challenges trump just about every single technology one. When I worked at Microsoft, we were dropped into client sites where the systems were down and companies were losing lots of money. The way they trained us for that was by putting us through a three-week, soft-skills boot camp. For that reason, I recommend Tech Leads looking at the soft skills side, and books like Crucial Conversations: Tools for Talking When Stakes Are High, How to Argue & Win Every Time: At Home, At Work, In Court, Everywhere, Everyday and Behind Closed Doors: Secrets of Great Management.

有什么时间管理技巧吗？

Any time-management tips?

让一切都可见：对于个人使用，个人看板之类的东西是非常宝贵的技术。想象你必须做的工作，以及它需要多长时间是非常宝贵的。

Make everything visible: for personal use, things like Personal Kanban are invaluable techniques. Visualising the work you have to do, and how long it is taking is invaluable.

我也不担心立即回复每封电子邮件。我不收件箱归零，但我确实将需要处理的电子邮件保留为未读。然后，当我有空闲时间时，我会返回并按未读排序，然后从下到上开始工作。这需要时间，但我最终得到了他们！

I also don’t worry about replying to every email immediately. I don’t do Inbox Zero, but I do leave emails that need to be handled as unread. I then go back when I have free moments and sort by unread, and start working from the bottom up. It takes time, but I get to them all eventually!

您如何在编写代码和处理其他问题之间取得适当的平衡？

How do you strike the right balance between writing code and dealing with other issues?

作为 Tech Lead，我的首要职责是我的团队，而不是我的代码。这意味着我可能会比其他成员工作更长的时间来跟上“相同”的工作量。或者我可能无法承担与他们一样多的工作。我的大部分时间都集中在教导和理解团队的挑战上，以确保他们尽可能顺利地工作。这并不总是那么容易 - 当然有时候我只想戴上耳机和代码，所以我这样做了。但这不可能一直如此。

As a Tech Lead, my first responsibility is my team, not my code. That means I might work longer hours than other members to keep up with the “same” workload. Or I might not be able to take on as much work as them. Most of my time is focused on teaching and understanding the challenges of the team to ensure they are working as smoothly as possible. It is not always easy - there are certainly times when I just want to put on headphones and code, and so I do. But that cannot be all the time.

Cory 的关键问题：Tech Leads 如何让其他人成为 Tech Leads？

Cory’s key question: How do Tech Leads prepare others to be Tech Leads?

我经常看到 Tech Leads 或架构师不想让位给他人。我们专注于指导和成长。我准备他人的方式是将决定强加给他们，让他们犯错。

I often see Tech Leads or architects who do not want to give their position up to others. We focus on mentorship and growth. The way that I prepare others is by pushing decisions to them and letting them make mistakes.

Cory 的第二个问题：你是如何学习、成长和跟上新技术的？

Cory’s second question: How do you learn, grow and keep up with new technology?

我认为手工艺运动背后的重要理念之一是，你作为个人对你的成长负责——而不是你的雇主、你的领导或你的经理。我发现花时间投资自己很重要。做一些阅读。参加或出席会议。参与用户组。所有这些活动都有助于防止您停滞不前。

I think one of the big ideas behind the craftsmanship movement is that you as an individual are responsible for your growth - not your employer, not your leads or your managers. I find it is important to take time to invest in yourself. Do some reading. Attend or present at conferences. Participate in user groups. All of these activities help prevent you becoming stagnant.

科里的背景故事

Cory’s background story

Cory 是一名技术专家和变革推动者。他热爱软件开发，热衷于发展组织。在过去的 15 年里，他一直从事软件工作，与全球各地的团队一起工作和交流。

Cory is a technologist and change agent. He loves software development and is passionate about growing organisations. He has worked with software for the past 15 years, working and speaking with teams all over the globe.

通往商业的桥梁——Ryan Kinderman

A Bridge to the Business – Ryan Kinderman

Tech Lead 应该关注什么？为什么？

What should a Tech Lead focus on and why?

项目经理和其他开发人员经常告诉我，我是“代理”技术主管，这对我来说意味着我是团队成员，可以最有效地与人们一起疏通团队，指导我们纠正软件主题的决策设计，并在项目规划和期望设定等领域提供帮助。这就是 Tech Lead 必须要做的事情。有可能分担领导责任，或者领导放弃或分散领导责任以专注于技术细节一段时间。

I have often told by project managers and other developers that I was the “acting” Tech Lead, which to me implied that I was the team member most effective in working with people to unblock the team, guide us to correct decisions on topics of software design, and help with areas such as project planning and expectation setting. That’s what a Tech Lead has to do. It’s possible to share lead responsibilities, or for a lead to relinquish or spread leadership responsibilities to focus on technical details for a while.

技术项目很复杂，我觉得作为 Tech Lead 我必须做的主要事情是充当项目中非技术和技术利益相关者之间的沟通桥梁。作为 Tech Lead，我需要能够以非技术利益相关者理解和接受的方式向他们解释技术概念。我还必须向非技术和技术利益相关者证明所做的技术决策是合理的，经常将这些决策与可能的许多可用替代方案进行比较。我还必须通过与项目经理和/或客户利益相关者的沟通，帮助技术团队根据我所学的知识了解正在构建的功能的上下文。要做到这一点，需要多种技能，包括技术和人际关系。

Technical projects are complex, and the principal thing that I feel I must do as a Tech Lead is act as the communication bridge between the non-technical and technical stakeholders on the project. As Tech Lead, I need to be able to explain technical concepts to non-technical stakeholders in a way that they understand and feel comfortable with. I must also justify the technical decisions being made to both non-technical and technical stakeholders, often comparing those decisions with possibly many available alternatives. I must also help the technical team understand the context for the functionality being built according to what I’ve learned by communicating with the project manager and/or client stakeholders. To be able to do this requires a wide variety of skills, both technical and interpersonal.

在项目的技术方面，其他职责包括与其他技术团队成员合作：

On the technical side of the project, other responsibilities include working with other technical team members to:

• 决定使用什么技术
• Decide what technology to use
• 了解如何正确使用技术来提供所需的功能
• Understand how to use the technology properly to deliver the desired functionality
• 建立开发方法，构建必要的功能，包括：
• Establish an approach for the development that will be done to build the necessary features, including:
• 应如何分解、组织开发任务并确定优先级
• How the development tasks should be broken up, organised, and prioritised
• 保持高水平的开发质量
• Maintaining a high level of quality for what is developed
• 随着行为随时间的变化，保护开发的功能免受回归
• Protecting developed functionality against regression as behaviour changes over time
• 通过参与代码审查和/或结对开发任务，并促进对所做决策的公开讨论，赢得开发团队的尊重和信任，并与他们平等相处。
• Earn the respect and trust of, and act as an equal to, the development team by participating in code reviews and/or pairing on development tasks and facilitate an open discourse on decisions being made.

鉴于成为 Tech Lead 所需的技能和理解的广度，我花了一些时间来缩小核心职责范围。大多数情况下，仅涵盖这些核心职责是不够的。有时项目缺少项目经理，或者项目经理缺乏应用正确管理流程的经验或知识。有时技术团队没有正确的技能组合，或者团队中初级开发人员与高级开发人员的数量不成比例。在这种情况下，如果项目有幸拥有一名 Tech Lead，则必须承担这些其他角色的一些责任才能使项目成功。

Given the breadth of skills and understanding required to be Tech Lead, it took me a while to narrow down the core responsibilities. Most of the time it isn’t enough to cover only those core responsibilities. Sometimes a project lacks a project manager, or the project manager lacks the experience or knowledge to apply the right management process. Sometimes the technical team doesn’t have the right skill mix, or there is a disproportionate number of junior to senior developers on the team. In such situations, the Tech Lead, if the project is lucky enough to have one, must assume some of the responsibilities of these other roles in order for the project to be successful.

你管理时间的秘诀是什么？

What are your secrets to managing time?

当谈到我的工作和职业生活时，我痴迷于优先考虑。我非常努力地确保我有一份清单，列出了所有需要或最终可能应该在项目、目标和环境中完成的事情。我会定期查看此列表并确保它的优先级准确。然后，我会非常专注地逐一完成清单上的项目。我尝试定期停下来检查电子邮件或以其他方式进行协作，有时是因为我列表中的项目，但通常是为了处理外部参与者，这些外部参与者正在改变我需要了解和工作的重点之外的条件进入我自己的优先列表。

When it comes to my work and professional life, I prioritise obsessively. I try very hard to make sure that I have a list of all of the things that need to, or potentially should eventually, get done across projects, goals, and contexts. I review this list regularly and make sure it’s accurately prioritised. I then work through the items on the list one by one with a strong focus. I try and pause at regular intervals to check email or collaborate in other ways, sometimes as a result of items in my list, but usually to deal with external actors that are changing conditions outside of my focus that I need to stay abreast of and work into my own prioritised list.

通过确保我有一个我需要做的事情的优先列表，我通常知道我在正确的事情上花费了我的时间，以正确的顺序。如果感觉我无法完成列表中的时间敏感项目，我会把它作为一个问题向其他人提出，并尝试委派或更新人们对何时完成的期望。

By making sure that I have a prioritised list of things that I need to do, I generally know that I’m spending my time on the right things, in the right order. If it feels as though I’m not going to be able to accomplish time-sensitive items from the list, I raise this as a concern to others, and try to delegate or update people’s expectations of when it will get done.

您如何在编写代码和处理其他问题之间取得平衡？

How do you strike the balance between writing code and dealing with other issues?

作为Tech Lead，我经常写代码是为了准确了解我所领导的团队中开发人员的经验，并与开发人员进行平等沟通。通过与团队中的开发人员一起编写代码，或者审查他们的代码并提供反馈，我了解了他们的个性和开发风格，以及长处和短处，他们也了解了我的。虽然这很耗时，而且我并不总是有这种奢侈，尤其是在我加入一个已经进行了一段时间的项目的情况下。

As Tech Lead, I often write code to gain an accurate understanding of the experience of a developer on the team I’m leading, and to communicate with the developers at an equal level. By coding with the developers on the team, or reviewing and providing feedback on their code, I learn about their personalities and development styles, as well as strengths and weaknesses, and they learn about mine. It is time-consuming though, and I don’t have always have that luxury, especially in situations where I’m joining a project that has been underway for a while.

我需要对所使用的技术有广泛而深入的了解，并对系统中实体的结构以及它们之间的交互有一个远见。如果我花时间单独让应用程序在我的开发机器上运行，跟踪代码的相关区域，思考设计含义，绘制出重要的位图，编写测试用例以确认假设或回答有关事情的问题，通常结果会更好工作等等。在此过程中我不咨询任何人；我以自己的方式学习事物并得出自己的理解。只有在这个过程之后，我才会与他人核对我的假设和理解。通过遵循这种做法，我可以学到更深层次的东西，避免用乏味的问题打扰团队，并赢得尊重。

I need to have a broad, intimate understanding of the technologies being used, and a vision of the structure of the entities in the system and interactions between them. It usually turns out better if I spend time alone getting the application running on my development machine, tracing through the relevant areas of code, thinking about design implications, diagramming out nontrivial bits, writing test cases to confirm assumptions or answer questions on how things are working, and so on. I don’t consult anyone during this process; I learn things on my own terms and come to my own understanding. Only after this process, do I check my assumptions and understanding with others. By following this practice, I learn things at a much deeper level, avoid bothering the team with tedious questions, and gain respect.

除了系统的配对、开发和分析之外，我还尝试检查进入系统的每一段代码。通常不可能审查每个提交并提供反馈，但至少通过审查每个提交，我可以通过各种方式提供延迟反馈。如果我注意到出现了软件设计问题，我可以考虑在确定未来工作范围时留出时间来解决这些问题。

In addition to pairing, development, and analysis of the system, I try and review every bit of code that goes into the system. It’s often impossible to review and provide feedback on every commit, but at least by reviewing every commit, I can provide deferred feedback in various ways. If I notice software design issues emerging, I can consider including time to address them when scoping future work.

一些活动——产品审查会议、高级范围界定、为即将到来的周期分解开发任务——需要时间来审查或处理进入系统的代码。有些事情我需要参与，但是比较少，一般一个季度一次左右。我认为尝试在项目的稳定或非活动期间完成此动手工作很重要。产品审查会议通常可以由开发或项目经理参加，他们将向我和团队汇报。为即将到来的周期分解开发任务通常可以作为开发任务本身分发给开发团队。如果团队主要是初级人员或有问题，这种方法可能行不通，但无论如何在这种情况下都应该限制项目。而不管，

Some activities - product review meetings, high-level scoping, breaking development tasks out for upcoming cycles - take time from reviewing or working with the code going into the system. Some things I need to participate in, but relatively infrequently, usually once a quarter or so. I think it’s important to try and time this hands-on work to be done during stable or inactive periods for the project. Product review meetings can usually be attended by a development or project manager, who will report back to me and the team. Breaking development tasks out for upcoming cycles can generally be distributed to the development team as development tasks themselves. This approach may not work if the team is primarily junior or has issues, but the project should be restricted in such cases anyways. Regardless, I will try to take on any or participate in particularly tricky or critical development break-out work myself.

有时，如果有更大的问题占用了我审查或编写代码的时间，我会评估团队能否在一段时间内保持合理的代码质量水平，同时解决这些问题。如果团队中有人可以依靠来保持高质量，我可能会这样做。如果我觉得不能离开团队来维护代码质量，我会让项目经理或客户利益相关者了解这一事实，以及继续开发的成本。通过这样做，我让他们有机会设定适当的期望、预算或任何必要的东西来纠正这种情况，或者处理我已经确定的潜在后果。

Sometimes, if there are greater issues that detract from my time to review or write code, I assess whether the team can maintain a reasonable level of code quality for a period of time, while I address those issues. If there is someone on the team that I can lean on to keep the bar for quality high, I might do that. If I don’t feel able to leave the team to maintain code quality, I let the project manager or client stakeholder aware of this fact, and the cost of continuing development. By doing this, I afford them the opportunity to set proper expectations, budgets, or whatever is necessary to correct the situation, or deal with the potential consequences I’ve identified.

Ryan 的关键问题：对于 Tech Lead 来说，从事工作之外的哪些活动对于保持在该领域的活力和相关性很重要？

Ryan’s key question: What activities are important for a Tech Lead to engage in outside of work to stay vital and relevant in the field?

按重要性顺序列出：

Listed in order of importance:

1. 在工作和生活之间保持平衡我相信包括 Tech Leads 在内的所有开发人员都应该花时间学习和提高他们的技能。有时，学习一门新语言或范式会花费很长一段时间，而这会扰乱您生活的其他部分。我试图通过将较大的任务分解成可以在几个小时内完成的较小任务来在专业发展和追求我的其他兴趣之间保持健康的平衡。
2. Maintain balance between work and life I believe all developers including Tech Leads should spend time learning and improving their skills. Sometimes learning a new language or paradigm absorbs long periods of time that upset other parts of your life. I try to keep a healthy balance between professional growth and pursuing my other interests by breaking bigger tasks into smaller tasks that can be completed in a few hours.
3. 深入了解良好的软件设计、良好实践和不同的开发风格我们的行业广泛而深入，有许多专业值得学习。我寻求了解超越任何特定实现或编程语言的概念。例如，著名的《设计模式》一书成了我的圣经，因为你可以在许多上下文和编程语言中应用这些概念，而不仅仅是一种特定的平台、工具或产品。
4. Develop a deep understanding of good software design, good practices and different development styles Our industry is broad and deep with many specialities to learn from. I seek to learn about concepts that transcend any specific implementation or programming language. For example, the famous book Design Patterns became my bible because you can apply these concepts in many contexts and programming language, not just one specific platform, tool or product.
5. 尽可能多地了解硬技术技能尽管我永远不会无所不知，但阅读并有时尝试各种技术是很有用的。阅读不同领域的文章通常会意外地与我在一两周后正在研究的问题相关。我尝试广泛阅读各种技术和问题领域，例如编写 Linux 内核模块到 EPUB 文件的结构。除了我订阅的网站和博客之外，我还付费订阅了一些专业出版物，例如“Linux 杂志”和“ACM 通讯”。我在家里用 Linux 和 kvm 构建的小型虚拟机 (VM) 实验室中试验项目。使用 VM 可以让我快速开始和停止实验。
6. Stay connected as much as possible on hard technical skills Even though I will never know everything, it’s useful to read and sometimes experiment with a wide variety of technologies. Reading in varied areas often ends up serendipitously relevant to a problem I am working on a week or two later. I try to read broadly across a wide variety of technologies and problem domains, such as writing a Linux kernel module through to the structure of an EPUB file. I pay for a subscription to a few professional publications such as “Linux Magazine” and “Communications of the ACM” on top of the websites and blogs I subscribe to. I experiment with projects on a small Virtual Machine (VM) lab at home built with Linux and kvm. Using VMs allows me to start and stop experiments quickly.

赖安的背景故事

Ryan’s background story

Ryan 从 10 岁左右开始就对计算机感兴趣，并且知道他长大后想用计算机做点什么。他在威斯康星大学奥什科什分校学习计算机科学，毕业后继续在一家美国银行工作，担任软件开发人员，在那里他尽可能多地了解用户案例和敏捷方法。然后他转到 ThoughtWorks，在那里他学习了敏捷项目管理和开发实践。

Ryan was interested in computers from around the age of 10 and knew he wanted to do something with computers when he grew up. He studied Computer Science at the University of Wisconsin, Oshkosh and after graduating went on to work for a US Bank as a software developer, where he learned as much as he could about user cases, agile methodologies. He then moved to ThoughtWorks, where he learned about agile project management and development practices.

他担任技术主管已有大约五年时间。

He has been a Tech Lead for about five years.

你

You

当我第一次阅读本节中的回复时，每个人似乎都在关注他们是如何担任 Tech Lead 角色的。一个人描述了他们的方法随着环境的变化而变化。许多 Tech Leads 还表示要提高自我意识；尤其要警惕成为团队中信息或决策能力的瓶颈。我特别喜欢从这些访谈中发现的是，您可以欣赏如何塑造 Tech Lead 角色以最适合您的技能并仍然取得成功。

When I first read the responses in this section, each person seemed to focus on how they approached the Tech Lead role. One person described their approach changing as the context changed. Many Tech Leads also remarked on becoming more self-aware; especially remaining vigilant against being a bottleneck of information or decision-making ability in the team. What I especially enjoyed discovering from these interviews was an appreciation of how you can shape the Tech Lead role to best fit your skills and still be successful.

适应新情况

Adapting to New Circumstances

当开发人员遇到新问题、新库或编程语言时，他们必须利用新技能。同样，技术主管必须利用不同的技能来处理不同的情况。例如，成为业务规划周期的一部分所需的技能与管理技术债务所需的技能大不相同。

When a developer encounters a new problem, or a new library or programming language, they must draw upon new skills. Likewise, the Tech Lead must draw upon different skills to handle different situations. The skills required to be a part of a business planning cycle, for example, are significantly different from those required to manage technical debt.

团队的变化也需要 Tech Lead 的关注重点发生变化。离开团队的开发人员可能会留下知识空白或额外的责任。技术负责人监控差距并找到弥合差距的方法。相比之下，加入团队的新开发人员可能具有完全不同的编码或工作风格，技术负责人现在必须找到重新调整团队的方法，以整合新人带来的方法。

Changes in the team also require a change in focus from the Tech Lead. A developer leaving the team may leave a knowledge gap or additional responsibilities. The Tech Lead monitors for gaps and finds ways to bridge them. In contrast, a new developer joining the team may have a completely different coding or working style and the Tech Lead must now find ways to realign the team integrating the approaches brought by the new person.

与作为开发人员相比，技术主管必须处理更多不同的情况，而且通常很少练习新技能。您需要培养更广泛的技能以更好地应对这些新情况。参加培训课程或阅读书籍，以提高您的沟通技巧以及对人和团队行为的认识。

A Tech Lead has to handle many more varied situations than they did as a developer, often with little practice in new skills. You need to develop a broader skill set to better cope with these new situations. Attend training courses or read books that improve your communication skills and awareness of people and team behaviours.

当您放弃 Tech Lead 角色而扮演全职开发人员时要小心。更广泛的问题可能会一直未被注意到，并且在不被观察到的情况下升级，直到它们太大而无法迅速解决。

Be cautious when you drop the Tech Lead role to play the full-time developer. Broader issues may remain unnoticed and escalate unobserved until they are too big to solve quickly.

让自己变得多余

Making Yourself Redundant

较新的 Tech Lead（错误地）将他们的角色视为具有最深厚技术技能的人。他们认为他们必须对技术决策拥有最终决定权，并且必须解决所有最困难的技术问题。

The newer Tech Lead (mistakenly) sees their role as a person with the deepest technical skills. They think they must have the final say on technical decisions, and must solve all of the most difficult technical problems.

这些访谈凸显了 Tech Lead 很少是技术技能最深的人。有效的 Tech Lead 必须具备足够的技术能力来促进与开发人员的会面，或者找到解决技术问题分歧的方法。然而，许多 Tech Leads 写道，他们试图不断寻找将责任委派给团队的方法。

These interviews highlight how the Tech Lead is rarely the person with the deepest technical skills. An effective Tech Lead must be technical enough to facilitate meetings with developers, or find ways to resolve disagreements on technical matters. However many Tech Leads wrote about trying to constantly find ways to delegate responsibilities to their team.

当 Tech Lead 决定所有棘手的问题或保留所有有趣的工作时，可能会出现以下情况：

When a Tech Lead decides on all the tough problems or keeps all the interesting work, the following scenarios could arise:

• 一个人开始觉得他们正在做所有“无聊的工作”，并决定在别处有更多有趣的机会
• A person starts to feel they are doing all the “boring work” and decides there are more interesting opportunities elsewhere
• 一个人感觉好像他们没有因为做出重要决定而受到重视，并寻求一个他们更受重视的地方
• A person feels as though they are not valued for making important decisions, and seeks a place they are more valued
• 关键决策停滞不前，因为他们等待 Tech Lead，后者正忙于其他职责
• Key decisions stall because they wait for the Tech Lead, who is busy with other responsibilities
• 作为 Tech Lead，您会感到压力，因为每个人都在不断要求您做出决定
• As a Tech Lead, you feel stressed because everyone is constantly asking for you to make a decision

为了解决决策瓶颈，技术主管想方设法将其委托给团队。有效的授权意味着将任务分配给合适的人。这需要 Tech Lead 和他们的开发人员之间的信任，并了解每个人拥有的技能和知识。一个有效的 Tech Lead 不断地朝着这个方向努力。

To resolve a decision-making bottleneck, the Tech Lead finds ways to delegate this to the team. Effective delegation means assigning the right person to the task. This requires trust between the Tech Lead and their developers and understanding what skills and knowledge each person has. An effective Tech Lead constantly works towards this.

如果你是 Tech Lead 和技术上最有能力的人，你应该开始培养其他人，这样你就可以在未来委托决策。除了最小的团队，您无法设计和实现功能并有效地承担其他 Tech Lead 职责。

If you are the Tech Lead and the most technically competent person, you should start growing others so you can delegate decisions in the future. In anything other than the smallest of teams, you cannot design and implement functionality and cover the other Tech Lead responsibilities effectively.

发挥自己的优势

Using Your Own Strengths

所有这些访谈都突出了人们如何以多种不同方式担任 Tech Lead 角色。每个人都发现了自己的长处，并找到了发挥它们的方法。他们还发现，有些任务并没有发挥他们的长处，但仍然需要去做。使用诸如StrengthsFinder 2.0之类的书籍来更多地了解自己。

All these interviews highlight how people approach the Tech Lead role in many different ways. Each person discovered their own strengths and found a way to put them to use. They also found that some tasks did not play to their strengths but still needed doing. Use books like StrengthsFinder 2.0 to learn more about yourself.

一些 Tech Leads 在沟通方面有优势。他们与业务人员建立了牢固的关系，因为他们可以轻松地以非技术人员认为易于理解的方式翻译技术问题。他们的沟通技巧帮助他们协调团队朝着同一目标努力，并在出现问题时清楚地表达出来。

Some Tech Leads have strengths in communication. They develop strong relationships with business people because they easily translate technical matter in ways that non-technical people find simple to understand. Their communication skills help them harmonise the team working towards the same goal and clearly articulate when things go wrong.

其他技术主管在预见未来方面具有优势。他们更擅长预测决策的未来影响并轻松管理技术债务。他们知道何时投入时间解决技术问题，或何时转入“完成任务”模式。

Other Tech Leads have strengths in seeing the future. They are better at projecting the future impact of decisions and easily manage Technical Debt. They know when to invest time in burning technical issues, or when to shift into “getting stuff done” mode.

也许 Tech Lead 的人际关系很强，既了解团队中出现的冲突，又密切了解每个人、他们的希望和目标，并找到使个人和团队目标保持一致的方法。他们了解培养员工并创造安全的培育环境的必要性。

Perhaps a Tech Lead is strong in relationships, both understanding the conflicts emerging in the team, closely getting to know each person, their hopes and goals and finding ways to align individual and team objectives. They understand the need to develop their people, and create a safe nurturing environment.

花时间了解自己。然后花时间寻找方法将这些优势应用到 Tech Lead 的角色中，使其成为您自己的角色。

Spend time understanding yourself. Then spend time finding ways to apply those strengths to the role of Tech Lead to make it your own.

管理自己——斯蒂芬·哈迪斯蒂

Managing Yourself – Stephen Hardisty

Tech Lead 应该关注什么？为什么？

What should a Tech Lead focus on and why?

当您在技术领导阶梯上攀升时，您会被赋予更多责任和不同类型的控制权。作为开发人员，您有责任针对明确定义的问题提出巧妙的解决方案；作为 Tech Lead，您有责任针对通常定义不明确的问题提出大型解决方案。这意味着您正在设定一个愿景并依靠其他人编写实现该愿景的代码，这在开始时可能会令人沮丧。

As you move up the Tech Leadership ladder, you are given more responsibility and a different kind of control. As a developer, you are responsible for coming up with neat solutions to well-defined problems; as Tech Lead, you are responsible for coming up with large solutions to often ill-defined problems. This means you are setting out a vision and relying on others to write the code that implements this vision, which can be frustrating to begin with.

抵制介入和接管的诱惑很重要。相反，你必须行使你继承的新控制权：让你周围的开发人员变得更好。使你周围的人在工作中做得更好的意愿和能力是中级和高级开发人员之间的区别。让人们在工作中做得更好的好处在于，它可以帮助您了解团队中哪些人受到挑战和自我提升的激励，以及哪些人对自己的能力感到满意。

It is important to resist the temptation to step in and take over. Instead, you have to exercise the new control you have inherited: to make the developers around you better. The willingness and ability to make the people around you better at their jobs makes the difference between a mid-level and a senior developer. The great thing about making people better at their job is that it helps you understand who on the team is motivated by a challenge and self-improvement and who is content with being adequate.

下一个障碍是定义“更好”。简而言之，这通常意味着以可预测的速度交付，很少搞砸，交付人们喜欢使用的东西并帮助其他人实现所有这些。但是，这些并不是特别有用的说明。您需要弄清楚需要鼓励哪些行为来实现这些目标，例如合理的测试方法、对用户的同理心以及频繁推送代码以降低风险并获得快速反馈。结对编程不仅是编写代码的好方法，也是展示这些行为的机会。您应该花时间以身作则或将开发人员联合起来，以便他们互相教授您认为他们需要改进的技能。

The next hurdle is defining “better”. In raw terms, it often means delivering at a predictable rate, rarely screwing up, delivering something that people love to use and helping others achieve all of these. However, these are not particularly useful instructions. You need to work out what behaviours need to be encouraged to achieve these things, such as a reasoned approach to testing, empathy for users, and pushing code frequently to reduce risk and gain rapid feedback. As well as being a great way to write code, pair programming is an opportunity to demonstrate these behaviours. You should take the time to either lead by example or couple developers together so that they teach each other the skills you feel they need to improve.

使你成为 Tech Lead 的因素之一是你很聪明，但这并不意味着你总是对的！在与团队讨论解决方案时，确保各方礼貌地倾听对方的意见，并探索所有解决方案。

One of the factors that makes you a Tech Lead is that you are clever, but this does not mean you are always right! When discussing solutions with the team, make sure all parties listen to each other politely and all solutions are explored.

应谨慎对待解决未来可能出现的次要问题的更大解决方案。如果解决方案导致您现在做更多的工作以考虑可能不会发生的事情，那么您很可能过度设计了。唯一真正有效的面向未来的方法是有意义的测试和尽可能少的代码。

The bigger solutions addressing a secondary problem that may come up in future should be treated with caution. If the solution results in you doing more work now in order to factor in something that may not happen, there is a strong chance that you are over-engineering. The only sort of future-proofing that really works is meaningful tests and as little code as possible.

作为 Tech Lead，您遇到的最大挑战是什么？

What has been your biggest challenge as a Tech Lead?

我经历过的最困难的情况发生在几年前。我计划、推动并启动了一个我认为需要四名开发人员并运行大约五个月的项目。

The most difficult situation I experienced happened a few years ago. I planned, promoted and started a project that I thought would require four developers and run for about five months.

几个星期以来，我们感觉一切都进展顺利。我的经理一定不这么认为，并且令我惊讶的是，为该项目增加了第二位技术主管和另外五名开发人员。我不想暗示另一个 Tech Lead 是错误的，或者他不是一个令人愉快的人，但我们经常不同意彼此的技术决策。无论闭门讨论了多少；获得了多少尊重的意见；产生了多少证据，我们坚持截然相反的观点。这些分歧常常导致开发人员之间的混淆，以及我和另一位 Tech Lead 之间的公开争执。这打击了士气。

For a few weeks we felt everything was going smoothly. My manager must have thought otherwise and, to my surprise, added a second Tech Lead and five more developers to the project. I wouldn’t want to suggest that the other Tech Lead was wrong or that he was anything but a pleasant person, but we often disagreed with each other’s technical decisions. No matter how much discussion happened behind closed doors; how many respected opinions were garnered; how much evidence was produced, we stuck to our diametrically opposing views. The disagreements often resulted in confusion between developers and public disputes between the other Tech Lead and me. This killed morale.

可以预见的是，这个项目在技术上很复杂、很晚、很贵，现在需要一种特殊的开发人员来进行维护：一个拥有我和其他技术主管的技能组合的开发人员。

Predictably, the project was technically complex, late, expensive, and now requires a special sort of developer for maintenance: a developer that shares both my skill set and that of the other Tech Lead.

虽然这段经历很不愉快，但它让我有机会反思在困难的情况下我应该如何公开表现。它告诉我，应该重新审视难以证明合理的人事和技术决策，当然，在一个受限项目中不应有超过一名 Tech Lead。

Although this experience was unpleasant, it gave me the opportunity to reflect on how I should behave publicly under difficult circumstances. It taught me that personnel and technical decisions that are hard to justify should be revisited and, of course, that there should not be more than one Tech Lead on a confined project.

这个故事有积极的一面。一个最初让我兴奋但最终变坏的项目的挫败感促使我做出了一个我考虑了几个月的决定：找另一份工作。我从来没有后悔过这个决定，我怀疑我留下的项目在没有我的情况下继续走上一条更加平静和专注的道路。

There is a positive side to this story. The frustration of a project that initially excited me but eventually turned sour prompted me to make a decision I had been pondering for months: to find another job. I have never regretted this decision and I suspect the project I left behind continued on a much calmer and more focused path without me.

有什么时间管理技巧吗？

Any time-management tips?

我的四个主要时间槽是：

The four main time sinks for me are:

• 阅读电子邮件
• Reading email
• 出席会议
• Attending meetings
• 管理和指导开发人员
• Managing and directing developers
• 编写代码
• Writing code

众所周知，无论内容多么重要，电子邮件都会让人分心。我有两种技术来确定电子邮件的优先级。对于低优先级的邮件，比如某些类型的全球邮件，我会自动将它们标记为“已读”，只有在我有时间的时候才会看一眼。对于其他电子邮件，我为直接发给我的客户电子邮件、发给我团队的电子邮件和其他电子邮件设置了不同的颜色。这有助于我快速决定我应该阅读一封电子邮件多长时间——从彻底理解到简单浏览。对于需要回复的电子邮件，我总是尽快回复以避免积压。这不仅让我不至于不知所措，而且还为发件人提供了他们希望得到的即时回复。

As we all know, email can be a distraction - no matter how important the content. I have two techniques for prioritising email. For low-priority emails, such as certain types of global emails, I have them marked automatically as “read” and only glance at them if I have time. For other emails, I have a different colour for client emails that come to me directly, emails that come to my team, and other emails. This helps me decide quickly how long I should read an email for - from thoroughly understanding to just a simple glance. For the emails that deserve a response, I always respond as quickly as I can to avoid a backlog. This not only keeps me from being overwhelmed but also gives the sender the immediate response they hopefully appreciate.

至于会议，我很幸运能在一家全体会议也通过互联网广播的公司工作。除非我必须出席，否则我会像对待收音机一样对待它们，在做其他工作的同时收听它们。在 Etsy，我们还有所谓的“Fixler 规则”（以我们的一位董事 Eric Fixler 的名字命名）。这条规则规定，当会议不再为你带来价值时，你可以礼貌地退出。我每周都会与开发人员进行一对一的交流，只要他们需要，他们就会持续很长时间。它们很重要，没有商量余地。如果您希望您的开发人员占用您更少的时间，一对一是倾听他们的担忧并帮助他们计划自我改进的完美论坛。

As for meetings, I am lucky enough to work for a company where all-hands are also broadcast via the internet. Unless my attendance is mandatory, I treat these like a radio and listen to them whilst doing other work. At Etsy we also have what we call the “Fixler rule” (named after one of our directors, Eric Fixler). This rule dictates that you may politely exit when a meeting has ceased to yield value for you. I hold developer weekly one-to-ones and they last for as long as they need to. They are important and non-negotiable. If you want your developers to use up less of your time, the one-to-one is the perfect forum for listening to their concerns and helping them plan self-improvement.

我将简要介绍代码部分：它是兼职的，我用它来放松和了解产品和开发人员的开发方式。我只选择非常小的、琐碎的任务，从不选择任何重要的任务，因为我不能保证我的时间。

I will leave the code part brief: it is part-time and I use it as both a way to relax and to keep in touch with how the product and developers are developing. I only ever pick very small, trivial tasks and never anything critical as I cannot guarantee my time.

在朝九晚五（或八晚八！）之外，保持健康的工作/生活平衡很重要。在业余时间，你应该在情感上尽可能地脱离工作。如果工作成为您主要的情感投资，您就有可能通过交付软件的能力来判断您作为一个人的整体成功。具有讽刺意味的是，压力和长时间工作会降低您的工作效率，而且无论您喜不喜欢，您都为同事树立了榜样。

Outside the nine-to-five (or eight-to-eight!), it is important to have a healthy work/life balance. You should emotionally detach from your work in your spare time as much as possible. If work becomes your main emotional investment, you risk judging your overall success as a human being by your ability to deliver software. Ironically, stress and long hours make you less effective at your job and, whether you like it or not, you set an example to your colleagues.

您如何在编写代码和处理其他问题之间取得适当的平衡？

How do you strike the right balance between writing code and dealing with other issues?

随着时间的推移，我对不编码变得更加自在。我仍在编写代码，但它通常仅限于非关键更改，因此我可以通过处理不会让我依赖的任务来了解整体情况。有时会出现一些计划外的事情，而当其他开发人员正在埋头做自己的工作时，我可以将事情改组并解决问题。我了解到这些不是证明“我仍然有魔力”的场合，而是找出可以改进的地方并进行我自己的小型事后分析。

Over time I have become more comfortable with not coding. I still write code but it’s generally limited to non-critical changes so I can keep in touch with how things are going overall by working on tasks that do not make me a dependency. There are occasions when something unplanned arises and while the other developers are heads down in their own work, I can shuffle things around and have a crack at the problem. I have learned that these are not occasions to demonstrate that “I still have the magic”, but to work out what things could be improved and to run my own mini post-mortem.

最初我觉得我的非编码职责是除了编写代码之外的。渐渐地，我逐渐意识到，我的努力应该集中在努力让我所依赖的人尽可能高效、富有挑战性和积极性上。

Initially I felt my non-coding responsibilities were in addition to writing code. Steadily, the realisation has sunk in that my efforts should instead be focused on trying to make the people I rely on as effective, challenged and motivated as possible.

Stephen 的关键问题：常见的陷阱有哪些，如何避免？

Stephen’s key question: What are some common pitfalls and how can you avoid them?

单点故障有时很难避免。一些开发人员喜欢“拥有”他们的作品。虽然承担责任显然是一件好事，但所有权的观念往往会导致一个人对某事拥有独家知识。让一个开发人员成为唯一理解复杂事物的人的风险是显而易见的，但您必须非常勤奋才能避免这种情况。有几种方法可以防止单点故障，但我的偏好是确保对给定代码区域具有专有知识的开发人员迅速转移到其他地方，以便另一个人可以接受挑战。结对编程是一个不那么刺耳的解决方案，只要两个开发人员在键盘上公平轮流并且都明白正在做什么。

Single Points of Failure are sometimes difficult to avoid. Some developers love to “own” their work. Although taking responsibility is clearly a good thing, the perception of ownership often leads to one person holding exclusive knowledge of something. The risk of having one developer be the only person to understand something complex is obvious, but you have to be incredibly diligent to avoid it. There are a few ways to prevent Single Points of Failure but my preference is to make sure the developer with exclusive knowledge for a given area of code is quickly moved on to something else so another person can take on the challenge. A less jarring solution is pair programming, as long as both developers take fair turns on the keyboard and both understand what is being done.

另一个陷阱可能是无缘无故做出的决定。直觉是一件了不起的事情，下意识的反应有时是你下意识地跳出来告诉你一些事情的经历。但是，在采取行动之前，您应该理解并能够解释这种反应。然后是另一种类型的非理性决定，这更糟糕：由自我驱动的决定。营造一种可以犯错的氛围很重要。无可指责的文化是做出明智决策的巨大财富。

Another pitfall can be decisions driven without reason. Gut instinct is a marvellous thing and knee-jerk reactions are sometimes your experience subconsciously popping up to tell you something. However, you should understand and be able to explain that reaction before acting upon it. Then there is the other type of irrational decision, and this is worse: decisions driven by ego. It is important to create an atmosphere where it is ok to be wrong. A blameless culture is an enormous asset to sensible decision-making.

斯蒂芬的背景故事

Stephen’s background story

Stephen 担任软件工程师已有 15 年了。18 岁时，他开始在英国布里斯托尔的 Logica 工作，帮助编写实时计费系统。从那以后，他一直在 MessageLabs（现在是 Symantec 的一部分）工作；为一家英国初创公司编写反垃圾邮件软件；作为澳大利亚墨尔本 realestate.com.au 的技术主管，目前是纽约 Etsy 的工程经理。他建立和管理团队已有大约七年的时间，并且意识到他更喜欢与小团队一起工作，以实现高度集中的目标。

Stephen has been a software engineer in some capacity for 15 years. He started working at Logica in Bristol, UK, when he was 18, helping to write real-time billing systems. Since then he has worked for MessageLabs (now part of Symantec); for a UK start-up writing anti-spam software; as a Tech Lead for realestate.com.au in Melbourne, Australia, and is currently an engineering manager at Etsy in New York. He has been building and managing teams for about seven years and has realised that he prefers to work with small teams on highly focused goals.

侦察——杰弗里·吉斯曼

Scouting – Geoffrey Giesemann

Tech Lead 应该关注什么？为什么？ Tech Lead 的角色可以有很大的不同，这取决于团队的组成和团队所处的组织环境。我喜欢将 Tech Lead 视为团队的侦察员。他们是您可以在主要工作之前派遣的人，以调查情况、发现障碍、回来并报告团队下一步应该去的地方。

What should a Tech Lead focus on and why? The Tech Lead role can vary widely, depending on the composition of the team and the organisational context the team is in. I like to think of a Tech Lead as the scout for a team. They’re the person you can send ahead of the main body of work to survey the landscape, spot obstacles, come back and report on where the team should head next.

对我来说，Tech Lead 的主要责任在于这个侦察隐喻。对于任何给定的项目，您都需要做出一堆技术决策，而做出这些决策所需的信息是分散的。其中一些甚至可能在公司外部，在您的客户或其他公司的同行的头脑中。作为 Tech Lead，您需要找出这些信息并将其提供给您的团队。

To me, the key responsibility of a Tech Lead lies along this scouting metaphor. For any given project you’ll need to make a bunch of technical decisions and the information you need to make those decisions is scattered. Some of it may even be outside the company, in the heads of your customers or peers in other companies. As a Tech Lead you need to ferret out this information and make it available to your team.

如果您在大型组织中，则相同的责任反过来起作用。如果您的团队正在工作，那么这项工作很可能会影响组织中的许多其他开发团队。作为 Tech Lead，您应该让其他团队了解您的团队正在进行的所有重大更改，以便他们在开展工作时可以将这些更改考虑在内。

If you’re in a large organisation, the same responsibility works in reverse. If your team is doing work, odds are the work will impact on a number of other development teams in the organisation. As a Tech Lead you should be making other teams aware of all the significant changes your team is making so that they can take them into account when they’re doing their work.

作为 Tech Lead，您遇到的最大挑战是什么？

What has been your biggest challenge as a Tech Lead?

我目前正在进行的项目非常大（大约 12 个月），我们与来自不同业务部门的多个利益相关者进行了接触。多个利益相关者的典型问题是他们都想要不同的东西，这取决于我们在开展工作时根据我们自己的优先事项来兼顾他们。

The project I am currently on is quite large (about 12 months) and we’re engaged with multiple stakeholders from different parts of the business. The classic problem with multiple stakeholders is that they all want different things and it is up to us to juggle them, along with our own priorities, as we do our work.

在这种特定情况下，有两种结果：一种是用更新的、闪亮的、性能更好的系统替换遗留系统；另一个是通过为客户提供更好的工具并使我们系统的一部分更加透明来让他们更快乐。尽管这两个结果是相关的（在同一个系统上工作），但它们是完全正交的，可以作为两个单独的项目运行。

In this specific case there are two outcomes: one is to replace a legacy system with a newer, sparkly, better-performing one; the other is to make our customers happier by providing them with better tooling and make part of our system more transparent. Although both outcomes are related (working on the same system), they’re completely orthogonal and could be run as two separate projects.

因此，我们必须定期调整结果以安抚各方，而这导致的低效率和延迟让我抓狂。

As a result, we have to periodically tack between the outcomes to appease the different parties, and the inefficiencies and delays this causes drive me nuts.

我不能说我处理得很好，但归根结底，你的项目利益相关者也是人，重要的是你不要让对他们世界观的不满滋生仇恨。我注意到的一个特别麻烦的事情是，当 IT 人员将公司的非 IT 部分称为“业务”时，他们轻蔑地挥手。我们都在同一家公司工作；我们所有人（理论上）都想要同样的东西，因此重要的是要正确看待这一点，不要让我们和他们的心态发展。

I cannot say I’ve handled it well, but at the end of the day your project stakeholders are human beings too, and it is important you don’t let discontent with their world view breed into hate. A particular bugbear I notice, is when IT people wave their hands dismissively when they refer to the non-IT part of the company as ‘the business’. We all work for the same company; we all (in theory) want the same thing, so it is important to keep that in perspective and not let an us-and-them mentality develop.

有什么时间管理技巧吗？

Any time-management tips?

需要关注的两件简单的事情是委派和消除无用的会议。

Two simple things to focus on are delegation and eliminating useless meetings.

委派很简单：你需要做这项工作还是可以将其交给其他人？（如果不重要，则完全忽略它）。有时这意味着将工作交给可能做得不好或可能比您花费更长的时间的人。这些是您需要承担的成本，我建议尽量让代表有机会在此过程中学习或提高技能。

Delegation is simple: do you need to do this work or can you hand it over to someone else? (or ignore it completely if it is not important). Sometimes this means handing over work to someone who may not do it as well or may take longer than you would have. These are costs you need to bear and I recommend trying to make it an opportunity for the delegate to learn or upskill in the process.

在会议方面（我在这里有点呼应 Rands），通常会召开会议，因为一群人需要做出决定或传播信息。如果会议的目的不明确，或者没有合适的人参加会议，我倾向于避免开会或找借口退出。

In terms of meetings (I am echoing Rands here a bit), a meeting is usually called because a bunch of people need to make a decision or to disseminate information. If the purpose of the meeting isn’t made clear, or the right mix of people aren’t at the meeting, I tend to avoid the meeting or find an excuse to opt out.

您如何在编写代码和处理其他问题之间取得适当的平衡？

How do you strike the right balance between writing code and dealing with other issues?

我仍然很喜欢写代码——有时我会休息半天，这样我就可以在键盘上私下消磨时间了。将我拉到管理链的更上层需要付出相当大的努力。

I still really like writing code - sometimes I take myself off for half a day so I can while away at the keyboard in private. It is going to take a fair bit of effort to drag me further up the management chain.

如果我长时间没有写代码，我会变得脾气暴躁，开始在团队中出气，这可不好。我尽量每周至少安排一次时间，这样我就可以对我想做的事情进行编码。这让我很开心，一个快乐的 Tech Lead 会让团队更快乐 :)

If I miss out on writing code for an extended period of time, I get grumpy and start taking it out on the team, which is not good. I try to box out time at least once a week so I can do coding on stuff I want to work on. This keeps me happy, and a happy Tech Lead makes for a happier team :)

Geoffrey 的关键问题：您为什么决定成为技术主管？

Geoffrey’s key question: Why did you decide to become a Tech Lead?

无数的原因。我想我已经明白并不是所有的问题都可以通过编写代码来解决（而且很多问题都是由它引起的）并且对于在同一领域工作的大量开发人员来说工作和思考是非常重要的在同一个方向。如果他们不这样做，混乱很快就会接踵而至。

A myriad of reasons. I think I reached a point where I understood that not all problems can be solved by writing code (and quite a few problems are caused by it) and that it is incredibly important for large groups of developers working in the same domain to work and think in the same direction. If they don’t, chaos ensues quickly.

我也相当擅长编程，我想我可以挑战一下。

I am also reasonably good at programming things and I figured I could use a challenge.

Geoffrey 的另一个问题：开发人员何时准备好成为 Tech Lead？

Geoffrey’s other question: When is a developer ready to become a Tech Lead?

简而言之，当他们意识到没有坏程序这样的东西时。

In short, when they realise there’s no such thing as a bad program.

我参与了一个工作项目，该项目需要将我公司编写的所有软件都迁移到另一个数据中心。这涉及阅读大量代码，并对其进行修改以使以前硬编码的值可配置。在此期间，我迁移了我们的主 Web 应用程序的副本，该应用程序在较早阶段分叉并用于通过备用渠道提供我们的内容。虽然代码是由一些没有经验的开发人员定制的，但它已经 18 个月没有经过任何产品开发或重构，这意味着它实际上非常简单，并且使用起来很愉快。我在大约四个小时内让它运行起来。

I was involved with a project at work that required migrating every bit of software ever written at my company to another data centre. This involved reading a lot of code, and modifying it to make previously hard-coded values configurable. During this, I migrated a copy of our main web application that was forked at an earlier stage and used to deliver our content via an alternate channel. Although the code was customised by some inexperienced developers, the fact that it had not undergone any product development or refactoring for 18 months meant that it was actually quite simple and a pleasure to work with. I got it running in about four hours.

这真的让我大开眼界，因为我突然明白了为什么那家公司的软件是这样的，以及它是如何到达那里的。它既欣快又有些沮丧。

This really opened my eyes in that I suddenly understood why software at that company was the way it was and how it got there. It was both euphoric and somewhat depressing at the same time.

Geoffrey 的背景故事 Geoffrey 担任 Tech Lead 仅两年多时间，领导了三个不同的团队。他作为程序员工作了七年多一点，现在受雇于墨尔本的澳大利亚房地产公司。当不在编程中时，Geoffrey 喜欢户外活动。

Geoffrey’s background story Geoffrey has played the Tech Lead role for just over two years, leading three different teams. He has worked as a programmer for slightly over seven years, and is now employed by Real Estate Australia in Melbourne. When not found inside programming, Geoffrey enjoys the great outdoors.

从后面领先——乔尔·托西

Lead from Behind – Joel Tosi

Tech Lead 应该关注什么？为什么？

What should a Tech Lead focus on and why?

最终，作为 Tech Lead，您将决定自己将成为什么样的领导者。很容易确定我作为 Tech Lead 担心的是什么：我不想成为依赖或头衔。这种担忧实际上让我之前考虑过拒绝领导角色。当我第一次被要求领导 Red Hat 的解决方案架构师时，我差点拒绝了。我觉得团队合作得很好，我们之间没有任何划分的必要。我努力想看看 Tech Lead 会填补什么空白，更重要的是，它会如何让团队变得更好。

Ultimately as a Tech Lead, you determine the leader you will be. It is easy to identify what I worry about as a Tech Lead: I don’t want to become a dependency or a title. This concern has actually made me consider turning down leadership roles before. When I was first asked to lead the solution architects at Red Hat, I nearly turned it down. I felt that the team was working fine together and there wasn’t any need for delineation amongst us. I struggled to see what void a Tech Lead would fill and, more importantly, how it would make the team better.

事后看来，我意识到这比头衔或职位更多地反映了我。Tech Lead 的头衔是你做的（除非你的经理把它当作微观管理工具，我见过）。

In hindsight, I realise that was more of a reflection of me than the title or the position. The title of Tech Lead is what you make it (unless your manager uses it as a micro-management tool, which I have seen).

所以 Tech Lead 应该关注的最重要的事情不是领导。“领导”一词意味着其他人是顺从的和跟随的。我更愿意专注于促进环境，我们都可以互相学习，每个人都可以尽力而为。无论我是在帮助我的团队成员审查代码或架构，还是只是听他们发泄，我都不想给人留下权威的印象，而是试图了解他们的立场。例如，如果有人选择使用我可能不同意的某种算法，我会尽最大努力了解他们做出该决定的思维过程，而不是说，“嗯，你知道，那是 O(n^2 ) 而且我认为你可以在 O(n) 中做到这一点。” 那是无稽之谈。

So the most important thing a Tech Lead should focus on is not leading. The word “lead” implies that other people are subservient and following. I prefer to focus on facilitating environments, where we can all learn from each other and everyone can do their best work. Whether I am helping my team members to review code or architectures or simply listening to them vent, I never want to come across as authoritative, but seek to understand their position. For example, if someone is choosing to use a certain algorithm that I might not agree with, I do my best to understand their thought process in reaching that decision, as opposed to saying, “Well you know, that is O(n^2) and I think you can do it in O(n).” That is nonsense.

作为 Tech Lead，您遇到的最大挑战是什么？

What has been your biggest challenge as a Tech Lead?

当我第一次领导一个团队时，我们面临着一个荒谬的项目截止日期。我知道这种情况无处不在，但想象一下，如果您愿意，一个项目在开始时估计需要一年的工作，但实际情况是您将在四个月后上线。为您提供的解决方案是引入更多的开发人员。所以我从一个四人小团队的成员变成了领导一个 10 人团队（六名顾问）。当然，作为领导，我必须确保新顾问立即高效工作，现有团队了解该做什么，完成我自己的代码，并设计下一阶段。

When I was first leading a team, we faced a ridiculous project deadline. I know that happens everywhere, but imagine if you would, a project where, at inception you estimate it will be a year of work, but the reality is you are to go live in four months. The solution you are offered is to bring in more developers. So I went from being a member of a small, four-person team to leading a 10-person team (six consultants). Of course, as the lead, I had to make sure the new consultants were immediately productive, the existing team understood what to do, finish my own code, and design the next phases.

简而言之：我们惨败。我们按时投入生产，平均每周工作 80 小时（一周，我们最多工作 102 小时），在投入生产约 8 小时后，项目被回滚。然后事后分析开始了，更多的开发人员被抛到这个问题上，并且它继续螺旋上升。最终，经过大约两个多月的混乱，我们让管理层明白我们需要放慢脚步，专注于代码、集成和环境的质量。

In brief: we failed miserably. We went to production on time, after working an average of 80 hours a week (one week, we maxed out at 102 hours) and after being in production for about eight hours, the project was rolled back. Then the post-mortems started, more developers were thrown at the problem, and it continued to spiral. Eventually, after about two more months of scrambling, we got management to understand that we needed to slow down and focus on the quality of our code, integration, and environments.

我是如何处理这种情况的？好吧，根据项目结果，非常糟糕。我们进行了代码审查；我试图让团队了解测试和依赖关系等。我试图强加质量并学习新框架（当时的 REST，Maven 构建，以及 JQuery 的第一次修订，更不用说向从未使用过的人发送消息了）之前的一个通知模型）然后它就爆炸了。

How did I handle the situation? Well, based on the project outcome, pretty poorly. We ran code reviews; I tried to get the team to understand testing and dependencies, etc. I tried to impose quality and learning new frameworks (REST back then, Maven build, as well as first revision of JQuery, not to mention messaging to people who had never worked with a Notifier model before) and it blew up.

从好的方面来说：没有人退出。我们有一个强大的团队，通过这一切保持联系。我们都在继续前进，我仍然与该团队的大多数人交谈。所以也许我并没有像我想象的那样糟糕。

On the upside: no one quit. We had a strong team that bonded through it all. We have all moved on, and I still speak with the majority of that team. So maybe I didn’t do as badly as I think I did.

有什么时间管理技巧吗？

Any time-management tips?

这取决于我所在的组织和角色。当我刚成为领导时，我认为忙于开会意味着我在保护我的团队，同时也在做重要而忙碌的工作。

It depends on the organisation and role I am in. When I first became a lead, I thought that being busy in meetings meant I was protecting my team, as well as doing the important, busy work.

后来，我开始在日历上划出团队时间。甚至后来，我开始留出一些时间给“我”的时间。

Later, I started blocking out time on my calendar for team time. And even later, I started blocking out some time for ‘me’ time.

这些天，我给自己设置了团队互动的提醒。我刚刚培养了一个团队的新成员——这个过程持续了八个多星期。即使那已经结束，我还是提醒自己每 2 周检查一次他，看看他过得怎么样。当然，它可以是关于代码、架构的，但首先也是最重要的是关于他以及他的工作方式。如果你不和你的同龄人一起工作，那么你就已经输了。

These days, I set myself reminders for team interactions. I just ramped up a new member of a team - a process that lasts upwards of eight weeks. Even though that has ended, I have set a reminder to myself to check in on him every 2 weeks, just to see how he is doing. It can be about code, architecture, certainly, but first and foremost it is about him and how he is doing. If you don’t work with your peers as people, then you have already lost.

所以我有个人提醒，不仅要在我的团队内部进行互动，还要在我的团队外部进行互动。我可能不会一直打他们，而且我并不是每隔一周在某个特定时间打电话给别人——临时打电话更自然。我仍然为自己留出时间；你必须保持清醒。

So I have personal reminders to interact not only within my team, but also outside of my team. I may not hit them all the time, and it’s not as though I am calling people every other week at a certain time - ad hoc is more natural. I still block out time for myself as well; you have to stay sane.

您如何在编写代码和处理其他问题之间取得适当的平衡？

How do you strike the right balance between writing code and dealing with other issues?

早些时候，我认为唯一的问题是代码问题。多年来，我意识到我们的大部分问题都是沟通问题。因此，我首先尝试尽可能地成为一名有效的倾听者，其次尽可能地成为一名有效的沟通者。

Early on, I thought the only issues were code issues. Over the years, I have realised that the majority of our issues are communication issues. So I try to be as effective a listener as possible first, and secondly as effective a communicator as possible.

诚实、透明和谦逊将永远为您服务。

Honesty, transparency, and humility will always serve you well.

乔尔的关键问题：你为什么想成为领导者？

Joel’s key question: Why do you want to be a leader?

我希望看到其他人变得比我更伟大，我希望看到团队变得更好。

I want to see others become greater than me and I want to see the team become even better still.

Joel 的第二个关键问题：您会向其他 Tech Leads 推荐哪些读物？

Joel’s second key question: What reading would you recommend to other Tech Leads?

Weinberg 的任何东西都很棒，但如果我必须选择一个，那将是系统设计的一般原则（尽管成为技术领导者也可能适合这种情况）。

Anything by Weinberg is amazing, but if I had to choose one, it would be General Principles of System Design (although Becoming a Technical Leader may also be fitting in this context).

系统设计和思考不仅塑造了我如何看待我与系统的交互，而且塑造了我的同事和团队。它帮助我提升我的团队并帮助他们质疑和学习超出他们最初构想的东西。System Design General Principals of System Design 是一本你可以阅读和理解的书，然后一段时间后——对我来说大约一个月——你就会受到打击。就像看到矩阵一样。我希望其他人也有类似的经历。

System Design and Thinking has shaped, and continues to shape, not only how I see my interactions with systems, but also my peers and my team. It helps me elevate my team and assist them with questioning and learning what’s beyond their initial conception. General Principals of System Design is a book that you can read and understand, then some time later - for me it was about a month - you just get hit. It is like seeing the matrix. I hope others have a similar experience.

乔尔的背景故事

Joel’s background story

Joel 目前担任 JBoss 北美解决方案架构师的技术主管。他之前曾在 VersionOne 担任敏捷顾问和 XP 教练，并在芝加哥商品交易所担任技术主管、经理和架构师。

Joel current works as the Tech Lead for Solutions Architects for JBoss North America. He has previously spent time as an agile consultant and XP coach for VersionOne and as a Tech Lead, manager and architect at the Chicago Mercantile Exchange.

Joel 作为 Tech Lead 的方法已经从“以身作则”演变为“从背后领导”。他目前的方法涉及更多的观察和帮助威胁、挑战或质疑，并且感觉他的方法使他更加了解作为 Tech Lead 的身份。

Joel’s approach as a Tech Lead has evolved from “leading by example” to “leading from behind”. His current approach involves more observing and aiding threatening, challenging or questioning and feels his approach makes him more aware as a Tech Lead.

了解自己——丹尼尔·沃辛顿-博达特

Understand Yourself – Daniel Worthington-Bodart

Tech Lead 应该关注什么？

What should a Tech Lead focus on?

我认为无论做什么，发挥自己的优势都很重要。在追求那个目标的过程中要冷酷无情，但要选择你的战斗。就我自己而言，我追求技术卓越高于一切，但这并不是说你也应该如此。确保为您的队友留出发挥自己优势的空间。

I think it is important to play to your strengths in whatever you do. Be ruthless and unrelenting in the pursuit of that goal, but choose your fights. For myself, I pursue technical excellence above all else, but this is not to say you should too. Make sure you leave room for your teammates to excel in their strengths too.

Tech Lead 的另一项任务是为您的团队解除封锁。有时你会成为英雄，但永远不要忘记你也可能需要成为看门人。

Another task for the Tech Lead is to unblock your team. Sometimes you will be the hero, but never forget you may also need to be the janitor.

作为 Tech Lead，您遇到的最大挑战是什么？

What has been your biggest challenge as a Tech Lead?

最大的挑战通常是实现起来最慢或最长的：我已经工作了三年来解耦许多业务关键系统。这是一个漫长的艰苦跋涉。像往常一样，挑战既有社会方面的，也有技术方面的。最大的挑战是不要忘记目标，不断地把一只脚放在另一只脚前面。

The biggest challenges are often the slowest or longest to achieve: I have been working for three years to decouple a number of business critical systems. It has been a long hard slog. As usual, the challenges are both social and technical. The greatest challenge is not losing sight of the goal and constantly putting one foot in front of the other.

我发现技术挑战来得又快又硬，但不可避免地交织在一起的交付和组织挑战使长期解决方案和短期时尚之间存在差异。不放弃！

I find that technical challenges come hard and fast, but the delivery and organisational challenges that are inevitably entwined make the difference between a long-term solution and a short-term fad. Do not give up!

有什么时间管理技巧吗？

Any time-management tips?

我发现的最好的事情就是生孩子；现在我几乎不需要睡觉了！

The best thing I have found is to have a kid; now I hardly need to sleep!

更严重的是，如果你像我一样杂乱无章，那么不要忘记寻求帮助。寻求帮助不仅可以帮助您，还可以让其他人站出来分担责任。

On a more serious note, if you are as disorganised as me, then do not forget to ask for help. Asking for help not only helps you, but also allows other people to step up and share the responsibility.

您如何在编写代码和处理其他问题之间取得适当的平衡？

How do you strike the right balance between writing code and dealing with other issues?

我想我们经常坐在键盘前写代码，试图强制输出代码。通常，我们从键盘上拿走的休息时间会让我们的潜意识为我们解决问题。结对编程也有很大帮助，因为当你不在时，你的结对可以继续直接解决问题，而你回来时会带着新的眼光，可能还会有新的解决方案。

I think we often try and force code out by sitting in front of the keyboard and writing code. Often the breaks we take away from the keyboard allow our subconscious to solve the problem for us. Pair programming also helps enormously as, when you are away, your pair can continue with the direct approach to the problem, while you will come back with fresh eyes and probably a new solution.

我认为我没有找到平衡，因为我一直在思考代码或编码。对我来说，问题实际上是停止。

I do not think I have found balance, as I am constantly thinking about code or coding. For me, the problem is actually stopping.

Dan 的关键问题：作为 Tech Lead，与人员领导相比，你认为你的角色实际上有多少是关于技术领导的？或者，您如何使技术领导决策长期有效？

Dan’s key question: As a Tech Lead, how much do you think your role is actually about technical leadership compared with people leadership? Or, How do you make technical leadership decisions stick in the long-term?

我认为答案就在问题中。我们可以向人们展示伟大的技术领导力和远见，但人们对问题的深刻理解需要时间。我们经常不得不允许人们（以一种安全的方式）失败，这样他们才能感受到在制定解决方案时必须平衡的力量的紧张。

I think the answer is in the question. We can show people great technical leadership and vision, but it takes time for people to gain a deep understanding of problems. We often have to allow people to fail (in a safe manner) so they can feel the tension of forces one has to balance in crafting a solution.

丹的背景故事

Dan’s background story

Dan 在 IT 领域工作了将近 18 年，在支持、网络和基础设施、质量保证、技术销售、咨询和软件开发等各个方面工作，服务于不同行业的 50 多个不同客户。

Dan has been in IT for nearly 18 years, working in all dimensions, from support, networks and infrastructure, quality assurance, technical sales, consultancy and software development that spans over 50 different clients in different industries.

在过去七年中，他最近担任过大约十个不同团队的技术主管。他喜欢在复杂中寻找简单。当丹不写代码时，他喜欢音乐、电影和书籍，此外还喜欢攀岩。

He has played the Tech Lead role most recently in the last seven years for about ten different teams. He loves finding the simple in the complex. When Dan is not writing code, he enjoys music, films and books in addition to a little bit of rock climbing.

寻找平衡——劳拉·帕特森

Finding Balance – Laura Paterson

Tech Lead 应该关注什么？为什么？

What should a Tech Lead focus on and why?

我认为这是一个非常有趣的问题，我认为没有简单或单一的答案。在我领导的团队中，没有两个是相似的；作为 Tech Lead，每个人都对我提出了不同的要求。对我来说，Tech Lead 最重要的素质是能够站在后面看大局，然后能够适应解决最紧迫的挑战，无论是架构考虑、代码质量、管理技术利益相关者、团队平衡、精简流程、团队幸福感或识别潜在问题。

I think this is a really interesting question, and I don’t think there is a simple or single answer to it. Of the teams I have led, no two have been similar; each has asked different things of me as a Tech Lead. To me the most important quality required of a Tech Lead is the ability to stand back and see the big picture and then the ability to adapt to fix the most pressing challenge, whether it’s architectural considerations, looking at code quality, managing technical stakeholders, team balance, slimming down process, team happiness or identifying potential issues.

在我的第一个 Tech Lead 角色中，我们最初开发了一个拥有许多潜在业务利益相关者的研发系统。技术堆栈众所周知，团队成熟并且习惯于一起工作，所以我面临的主要挑战是确定哪些功能最有用，以及哪些架构可以确保所需的灵活性。

In my first Tech Lead role, we were initially developing a research and development system that had many potential business stakeholders. The technology stack was well known, the team was mature and used to working together, so the key challenges I had were identifying which features were going to be most useful and what architecture would ensure the required flexibility.

最近的一次演出启动了一个全新的媒体项目。客户知道他们想要什么，并且花了很多时间与设计机构一起确定他们想要的功能，并且我们已经明确定义了跨功能需求。在这个项目中，我的主要职责是指导架构选择，与技术利益相关者联络，并帮助陆上和海上团队建立良好的工作实践。

A more recent gig was kicking off a green-field media project. The client knew what they wanted and had spent a lot of time with a design agency establishing what features they wanted, and we had well defined cross-functional requirements. On this project my main role was guiding the architectural choices, liaising with technical stakeholders, and helping the onshore and offshore teams establish good working practices.

我相信 Tech Lead 的角色不是发号施令，而是帮助团队交付成果。如果 Tech Lead 去度假，世界不应该崩溃，团队应该感到有权做出自己的选择。团队越初级，Tech Lead 可能需要做更多的工作来指导技术决策和开发实践。一项关键技能是有效沟通 - 向内和向外。

I believe the role of a Tech Lead is not to dictate, but to help the team deliver. The world shouldn’t fall apart if the Tech Lead goes on holiday, and the team should feel empowered to make its own choices. The more junior the team, the more the Tech Lead may need to do to guide technical decisions and development practices. A key skill is communicating effectively - both inwards and outwards.

作为 Tech Lead，您遇到的最大挑战是什么？

What has been your biggest challenge as a Tech Lead?

我作为开发人员加入了一个大型项目，由于有人离职，我很快被要求成为 Tech Lead。团队很大：六七对开发人员，庞大的代码库已经使用了一年，而且由于最初的交付压力很大，因此相当单一。由于在庞大的代码库中工作了这么长时间，团队变得昏昏欲睡，庞大的团队规模减少了代码的所有权，并且难以在代码模式和质量方面建立一致性。此外，还有关于满足某些跨职能要求 (CFR) 的担忧。尽管安排了结对日并尝试跟上 Scala 的速度，这对我来说是个新事物，但我发现自己几乎没有时间花在代码上，所以我不得不寻找其他方法来查看我能看到的问题。幸运的是，我正在与一些非常了解代码库的优秀首席开发人员一起工作；能够信任他们让我有信心去审视一些团队范围内的问题。我们能够相当快地将团队分成三个业务领域，这提高了代码所有权和团队热情。

I joined a large project as a developer and was quickly asked to become Tech Lead due to someone leaving. The team was large: six or seven developer pairs, the large codebase was a year old and, due to a heavy initial push for delivery, fairly monolithic. The team was lethargic from working in a sprawling codebase for so long, and the large team size had reduced ownership of code and made it difficult to create consistency in code patterns and quality. In addition, there were concerns about meeting some cross-functional requirements (CFRs). Despite blocking out pairing days and trying to come up to speed with Scala, which was new to me, I found myself with little time to spend on the code, so I had to find alternative ways to look at the issues I could see. Luckily I was working with some great lead developers, who knew the codebase well; being able to trust them gave me confidence to look at some of the team-wide issues. We were able to split the team up into three business areas fairly quickly, which improved code ownership and team enthusiasm.

我与企业和团队一起举办了一系列研讨会，以准确确定 CFR 的要求，以及我们在当前解决方案中离实现这些目标还有多远，基本上暴露了系统中隐藏的技术债务。我们研究了“更软”的 CFR，例如可测试性和可维护性，以及更容易衡量的 CFR，例如性能。由此，我们能够创建一个技术待办事项列表，其中的项目标记为影响和改变的努力。通过确定对业务的影响，我们能够对列表进行优先排序，并确保有能力修复我们最重要的技术债务。

I ran a series of workshops with the business and the team to identify exactly what was required in terms of CFRs, and how far we were from achieving them in the current solution, essentially exposing the hidden technical debt in the system. We looked at ‘softer’ CFRs such as testability and maintainability as well as more easily measurable ones such as performance. From this we were able to create a technology backlog, with items marked for impact and effort to change. By identifying impact on business, we were able to get the list prioritised, and secure capacity to fix our most significant technical debt.

有什么时间管理技巧吗？

Any time-management tips?

我已经尝试了很多东西！便利贴、番茄工作法、思维导图、在我的日记中划出时间让我有时间远离 BAU，并确定配对日。目前对我有用的是在早上离开家之前检查我的日历并阅读我的电子邮件。这让我及时了解可能在一夜之间发生的任何事情或我当天需要做的任何事情。我让它在上班的路上渗透，这样当我开始工作的时候，我的脑海里就有了我今天想要实现的目标。那我写下来！有时在便利贴上，有时在 Evernote 上。每当我做任何事情时，我都会在 Evernote 中记录下来。这让我可以继续我清单上的下一个目标。我有一个令人震惊的记忆，所以一切都记下来了。当事情发生时，我可以在当天添加到我的列表中，但是有了列表，我可以看到什么东西从底部撞了下来，并确保它在第二天发生。如果某件事经常被撞到，我会打电话问我是否需要做，或者其他人可以做，还是我可以把它扔掉。有时重要的必须优先于紧急的；把它写下来有助于我理解如何创造这种平衡。

I’ve tried many things! Sticky notes, the Pomodoro Technique, mind maps, blocking out time in my diary to give me time away from the BAU, and identifying pairing days. What currently works for me is checking my calendar and reading my email before I leave the house in the morning. This brings me up to date with anything that may have happened overnight or anything that I need to do in the day. I let this percolate on the journey to work so that by the time I get to work I have a pretty good idea in my head of what I want to achieve in the day. Then I write it down! Sometimes on stickies, sometimes in Evernote. Whenever I do anything, I write it up in Evernote. This lets me move on to the next goal on my list. I have a shocking memory, so everything gets written down. I can add to my list in the day, as things come up, but by having a list, I can see what gets bumped off the bottom and make sure it happens the next day. If something gets bumped too often, I make a call on whether I need to do it or can someone else do it, or can I bin it. Sometimes the important has to take precedence over the urgent; writing it down helps me understand how to create that balance.

您如何在编写代码和处理其他问题之间取得适当的平衡？

How do you strike the right balance between writing code and dealing with other issues?

自八年前我担任第一个 Tech Lead 角色以来，这是我一直在努力解决的问题。这对小团队来说很容易，但随着更多的开发人员或政治因素发挥作用，就会变得更难。在更复杂的团队中，我发现如果沉浸在一个故事中，很难保持更广阔的视野。我认为，充其量，这是一个只能缓解的领域。为了有效地做到这一点，我问自己，在这个项目上，我希望从结对中获得什么好处，以及实现它们的最佳方式是什么。一些常见的好处是：了解代码库，培养初级开发人员的技能，使开发与架构愿景保持一致，亲身体验痛苦。配对可能是获得这些好处的最佳方式，但如果这不可能，还可以使用哪些其他工具？查看代码更改以与代码库保持同步。每周技术评论，每天的技术会议让两人有机会与团队分享他们的成就和关注点。事实上，这可以追溯到我之前关于什么对 Tech Lead 很重要的回答。对我来说，关键是要对项目保持清晰的整体愿景，并且在应对项目的日常潮起潮落时不要忽视这一点。

This is something I’ve battled with since my first Tech Lead role eight years ago. It is easy on a small team, but gets harder as more developers or political factors come into play. On more complex teams I find it difficult to retain a broader perspective if immersed in a story. I think, at best, this is an area that can only be mitigated. To do this effectively, I ask myself, on this project, what are the benefits I hope to get from pairing, and what is the best way to realise them. Some usual benefits are: understanding the codebase, developing skills in junior developers, aligning development with architectural vision, to feel pain first hand. Pairing may be the best way to reap these benefits, but if this is not possible, what other tools can be utilised? Reviewing code changes to keep current with the code base. Weekly tech reviews, and daily tech huddles give an opportunity for pairs to share their achievements and concerns with the team. In fact, this goes back to my previous answer about what is important to a Tech Lead. The key thing for me is to maintain a clear overall vision of the project and not to lose sight of that when responding to the daily ebb and flow of a project.

Laura 的关键问题：当您第一次担任 Tech Lead 角色时，您会做哪些不同的事情？

Laura’s key question: What would you have done differently the first time you stepped into the Tech Lead role?

我希望我能寻求更多帮助。在我领导的前几个项目中，我尝试自己做所有事情：编写代码、组织测试策略（因为我们没有单独的 QA）以及验证需求（因为那是过去美好的瀑布时代）。幸运的是，团队规模小且组织良好，因此我们能够交付。但我筋疲力尽，这对我或团队来说都不是愉快的经历。

I wish I’d asked for more help. In the first couple of projects I led, I tried to do everything myself: writing code, organising a test strategy as we had no separate QAs, and validating requirements as it was the good old waterfall days. Luckily the team was small and well formed, so we were able to deliver. But I was exhausted, and it was not an enjoyable experience for me or the team.

在第二场演出中学习授权艺术的愿望开启了我的敏捷之旅。

It was a desire to learn the art of delegation in the second of these gigs that started me on my journey in agile.

劳拉的背景故事

Laura’s background story

劳拉 (Laura) 拥有丰富多样的经历，在转向 IT 之前拥有英国文学和经济学背景。从那时起，她在媒体、出版、电信、国防、银行和慈善机构等多个行业的大约八个团队中担任技术主管。

Laura has a rich and varied history with a background in English Literature and Economics before transitioning into IT. She has played the Tech Lead role for about eight teams since then in a variety of industries including media, publishing, telecommunications, defence, banking, and charities.

她对使用敏捷实践来释放与她合作的团队的潜力有着浓厚的兴趣。

She has a strong interest in using agile practices to unlock the potential in the teams she works with.

结论

Conclusions

当我开始这本书的项目时，我不确定人们会给出什么样的回应，我也不确定是否有人会对这个话题感兴趣。当我与开发人员和潜在的面试候选人分享这个想法时，我提出的问题让他们感到困惑，因为他们无法说出许多解决这些重要问题的书籍。

When I started this book project, I wasn’t sure what sort of responses people would give, nor was I sure if there would be any interest in this topic. As I shared the idea with developers and potential interview candidates, the questions I posed puzzled them because they could not name many books that tackled these important issues.

许多人可能会翻阅描述如何编写更好的代码或如何设计和构建健壮的应用程序的书籍和资源。其他人知道教授一般领导力、沟通和管理理论的书籍和资源，但开发人员和 Tech Leads 对它们的普遍性、缺乏背景以及不一定与 Tech Lead 角色完全相关感到沮丧。

Many people could reel off books and resources that described how to write better code or how to design and build robust applications. Other people knew of books and resources that taught general leadership, communication, and management theory, but developers and Tech Leads expressed frustration about their generality, lack of context, and not necessarily being entirely relevant to the Tech Lead role.

在一口气阅读完所有回复后，我对某些主题出现的频率以及人们如何一次又一次地回到相同主题感到着迷。在本节中，我总结了这些反复出现的主题，以及它们如何阐明 Tech Lead 角色的不同方面。

After reading through the responses in one sitting, I was fascinated by how frequently certain themes emerged and how people would return to the same topics time and time again. In this section, I summarise those recurrent themes and how they shed light on different aspects to the Tech Lead role.

新任技术主管的经验教训

Lessons Learned by First-Time Tech Leads

从一个你专门编写代码的角色转变为一个只编写代码的一小部分的角色，这常常让人感到惊讶。以下是First-Time Tech Leads提到的课程：

The transition from a role where you exclusively write code to one where writing code is only a small part is what often takes people by surprise. Here are lessons the First-Time Tech Leads touched upon:

• 拥有更广阔的视野——超越单一功能或代码的想法，看到整个团队和业务的广度。
• Having a broader outlook - Moving beyond the thoughts of a single feature, or code and seeing the whole breadth of the team and business.
• 感受到更大的责任——伴随头衔而来的权威需要更大的责任感；您不仅要对自己的决定负责，还要对团队中每个人的决定和行动负责。
• Sensing greater responsibility - The authority that comes with the title requires greater accountability; you are accountable not only for your decisions, but the decisions and actions of each person on the team.
• 指导技术愿景——更多的责任和更广阔的前景相结合，当个人朝着不同的方向前进时会引起担忧。您花更多时间从技术角度提供指导。
• Guiding the technical vision - The combination of more responsibility and a broader outlook gives rise to concerns when individuals move in different directions. You spend more time providing direction from a technical point of view.
• 减少编写代码的时间——你必须重新定义如何为团队带来价值。您必须查看如何使其他人能够贡献高质量的代码，这些代码需要很少的返工并交付给业务需求，而不是您交付的代码或功能的数量。
• Coping with less time writing code - You have to redefine how you bring value to the team. You have to look at how you enable others to contribute quality code that requires little rework and delivers to business needs rather than the amount of code or features you deliver.
• 处理更多的上下文切换——技术主管角色挑战你的时间和任务管理能力，因为更多的人会打断你的澄清、指导和建议。紧迫的问题会让您远离代码编写，因此您需要注意不要为关键路径做出贡献或持有团队的独特知识。
• Juggling more context switches - The Tech Lead role challenges your time and task-management capabilities as more people will interrupt you for clarification, guidance, and advice. Burning issues draw you away from code-writing, so you need to beware of contributing to the critical path or holding unique knowledge from the team.
• 允许人们失败——你不能同时无处不在，尽管你很想告诉人们要避免的陷阱，但你必须承认，有时人们通过失败学习得最好。相反，您可以通过提高反馈循环的速度来确保失败的影响很小。
• Allowing people to fail - You cannot be everywhere at once and, as much as you want to tell people the traps to avoid, you have to accept that sometimes people learn best by failing. Instead you ensure failure has a small impact by improving the speed of feedback loops.
• 意识到人的方面很困难——作为开发人员，您大部分时间都在与计算机打交道。你可以脾气暴躁，而计算机没有反应。您意识到每个人都是独一无二的，因此对您的互动会有不同的反应。突然之间，您有责任解决冲突，而在此之前，您可以默默地溜走。
• Realising people aspects are hard - As a developer, you deal with computers for most of the time. You can act grumpily and the computer doesn’t react. You realise that everyone is unique and so reacts differently to your interactions. Suddenly you are responsible for resolving conflicts when, before, you could silently slip away.

实践技术主管的经验教训

Lessons Learned by Practising Tech Leads

这位经验丰富的 Tech Lead曾与多个团队合作过，可能来自不同的组织。他们的评论往往代表了从犯错和吸取教训中获得的智慧，并有机会将这些教训应用到新的环境中。从 Practicing Tech Leads 中吸取的经验总结如下。

The seasoned Tech Lead has worked with several teams, possibly across different organisations. Their commentary often represents wisdom gained from making mistakes and learning from them, having had a chance to apply those lessons in a new context. The lessons learned from Practising Tech Leads are summarised below.

人们

People

• 保持技术基础- 如果您仍然与团队一起编写代码，其他开发人员会更加尊重您。如果您接触过代码，您对问题的理解也会提高。
• Remaining technically grounded - Other developers respect you more if you still write code with the team. Your understanding of the issues also improves if you have contact with the code.
• 寻找和培养优秀人才——作为技术主管，您有责任聘请一支优秀的团队。您不能依赖在瞬息万变的市场中招聘人才，因此您需要培养团队中的人才并营造鼓励学习的环境。
• Finding and developing good people - As a Tech Lead you are responsible for hiring a great team. You cannot rely on hiring people in an ever-changing market and so you need to develop the people in your team and create an environment that encourages learning.
• 倾听团队的意见——作为开发人员，您可能大部分时间都在发表意见。您的 Tech Lead 角色要求您现在听取所有意见并在这个杂音中找到最佳解决方案。
• Listening to the team - As a developer, you probably spend most of your time giving opinions. Your Tech Lead role requires you to now listen to all the opinions and find the best solution within this cacophony.
• 欣赏个人优势——你会欣赏人们不同的行为方式，有时也会感到沮丧。你开始认识到不同的长处，并找到最能发挥人们这些长处的方式和情况。
• Appreciating individual strengths - You will appreciate and sometimes be frustrated by the way people behave differently. You start to recognise different strengths and find ways and situations where people’s these are best applied.

Tech Lead 的“技术”

The “Tech” of a Tech Lead

• 指导技术解决方案——技术负责人负责所有共享相同技术愿景的人。您使用架构图和白板会议来帮助在团队内建立共识，从而帮助人们保持一致。
• Guiding the technical solution - A Tech Lead is responsible for everyone sharing the same technical vision. You use architecture diagrams and whiteboard sessions to help build a shared understanding within the team to help align people.
• 协调团队方向——在开发团队中，没有什么比通过源代码控制系统自行解决的冲突更具破坏性的了，不同的意见通过冷嘲热讽的提交消息表达，或者通过覆盖别人的风格。技术负责人会发现方向上的冲突和差异，并帮助团队重回正轨。
• Harmonising team direction - Nothing is more destructive in a development team than conflict that resolves itself through the source control system, with different opinions expressed through snide commit messages, or by overwriting someone else’s style. A Tech Lead detects conflicts and differences in direction and facilitates the team to get back on track.
• 管理技术风险——软件有很多潜在的陷阱，必须有人确保它们不会被遗忘。作为 Tech Lead，你的职责是想方设法提高对技术风险的可见性和共同理解，并想方设法作为一个团队来解决这些问题。
• Managing technical risks - Software has so many potential traps and someone must ensure they don’t get forgotten. Your role as a Tech Lead is to find ways to create visibility and shared understanding of technical risks and to find ways as a group to address them.
• 从长远来看——开发人员更有可能关注他们的功能或贡献的非常狭隘的观点。Tech Leads 更担心今天的选择将如何变成明天的问题领域。
• Taking a longer-term view - Developers are more likely to focus on a very narrow view of their feature or contribution. Tech Leads worry more about how the choices of today will turn into the problem areas of tomorrow.

将业务与技术联系起来

Bridging the Business with Tech

• 建立信任——作为一名开发人员，您将大部分时间花在细节上，与业务其他部门的人员进行互动，以找出构建正确功能所需的内容。当您担任 Tech Lead 角色时，您会花更多时间与关键业务利益相关者建立关系；成为技术团队的“关键人物”。
• Building trust - As a developer, you spend most of your time in the details, interacting with people from other parts of the business just enough to work out what you need to build the right feature. As you move into the Tech Lead role, you spend more time building relationships with key business stakeholders; becoming the “go-to” person from the technical team.
• 为技术腾出时间- 屈服于业务压力以添加更多功能很容易。确保以可持续的方式完成是 Tech Lead 平衡的一项关键挑战。对企业的强烈信任使这成为可能，转化技术投资的好处有助于建立更好的理解。
• Finding time for technology - Bowing to the pressures from the business to add more features is easy. Ensuring that it is done in a sustainable way is one key challenge that the Tech Lead balances. Having a strong trust with the business makes this possible and translating the benefits of investing in technology helps build better understanding.
• 使技术解决方案易于理解——软件在很多方面都很复杂，充满了术语、不断变化的品牌和想法。作为一名经验丰富的 Tech Lead，您知道如何简化技术解决方案，并且可以找到类比或故事来帮助非技术人员充分了解技术领域，从而帮助他们做出更好的决策。
• Making technology solutions easy to understand - Software is complex in many ways, filled with terminology, constantly changing brands and ideas. As an experienced Tech Lead, you know how to simplify the technical solution and can find analogies or stories to help non-technical people understand the technical landscape enough to help them make better decisions.
• 影响规划——当你在简化技术想法方面建立了强大的信任和技能时，你将不可避免地被吸引到更多关注未来的会议中，这些会议可能涉及预算或项目规划，因为人们将你视为一个重要组成部分。你要仔细权衡这一点，因为离开团队的时间越长，你自己信息的新鲜度就越低。
• Influencing planning - When you have built strong trust and skill in simplifying technical ideas, you will inevitably be drawn into more future-focused sessions that might involve budgeting or project planning, because people see yours as an important component. You balance this carefully because more time away from the team reduces the freshness of your own information.
• 支持业务需求——有时技术团队会偏离对最终用户和为他们服务的业务模型的理解。技术主管将更大的图景带回团队，并阐明技术解决方案如何影响最终用户，以及业务目标是什么。有了这些知识，一旦团队了解将使用什么以及如何使用解决方案，他们就可以在解决方案保真度方面做出更好的权衡。
• Championing business needs - Sometimes technology teams drift away from understanding end users and the business models that serve them. Tech Leads bring that bigger picture back to the team, and clarify how technical solutions impact end users, and what the business goals are. With this knowledge, the team can make better trade-offs in solution-fidelity once they understand what and how a solution will be used.

你

You

• 适应新环境——从本书的回答中，你可以看到 Tech Lead 可能会遇到多少不同的情况，以及应对这些情况所需的丰富技能。您必须找到培养以前可能从未有机会培养的技能的方法。
• Adapting to new circumstances - From the responses in this book, you can see how many diverse situations Tech Lead may find themselves in and the richness of skills needed to deal with them. You must find ways to build skills you may never have had a chance to develop before.
• 让自己变得多余——虽然你可能会发现扮演“英雄技术主管”自己做所有事情很容易，但从长远来看，这是不可持续的，也不会扩展到更大的团队。你专注于培养人才并寻找委派任务的方法，这样你就可以花更多时间“只做一名开发人员”。
• Making yourself redundant - Although you may find it easy to play the “Hero Tech Lead” who does everything on their own, it is not sustainable over the long term, nor does it scale to a bigger team. You focus on developing people and finding ways to delegate tasks so that you can spend more time “just being a developer”.
• 利用自己的优势——每个人都有自己成为 Tech Lead 的方法，当被推到这个角色时，你会花更多的时间反省自己能提供什么并慷慨地应用它。
• Using your own strengths - Everyone has their own approach to being a Tech Lead, and when thrust into this role, you spend more time introspecting about what you can offer and apply it generously.

最后的话

Final Words

我希望你喜欢阅读我书中人物的故事，就像我喜欢收集和反思他们一样。有些人的故事可能比其他人更能引起共鸣，如果你发现自己处在不同的环境中，我鼓励你重新阅读这些故事，因为你可能会发现别人的故事比以前更能引起共鸣。

I hope that you have enjoyed reading the stories from the people in my book as much as I enjoyed gathering and reflecting on them. Some people’s stories may have resonated more strongly than others, and if you find yourself in different circumstances, I would encourage you to read the stories afresh as you may find that someone else’s stories resonate more than they did previously.

我希望我的书能帮助您更清楚地了解 Tech Lead 角色的作用。Tech Lead 的角色与开发人员的角色非常不同。您突然不得不在技术理解深度与人员方面取得平衡，并抽出时间与业务部门建立关系。您将面临培养这些新技能的新挑战。你突然发现自己要对更多的人负责，而不仅仅是你自己，而且你发现当涉及到人时，很少有“正确”的答案。

I hope my book has helped to give you a clearer understanding of what a Tech Lead role does. The Tech Lead role is very different from that of a developer. You suddenly have to balance depth of technical understanding with the people side and find time to build relationships with the business. You face new challenges building these new skills. You suddenly find yourself responsible for more people than just yourself and you discover that there is rarely any “right” answer when it comes to people.

幸运的是，您不是第一个开始担任这一角色的人，有了这本故事和课程集，您会为此做好更好的准备。

Fortunately, you are not the first to embark on taking on this role and, with this collection of stories and lessons in hand, you will be better prepared for it.

附录

Appendix

有用的书

Useful Books

Allen, David：完成工作：无压力生产力的艺术，Penguin Books，2002 年。

Allen, David: Getting Things Done: The Art of Stress-Free Productivity, Penguin Books, 2002.

伊恩·艾尔斯 (Ayres, Ian)：胡萝卜加大棒：释放激励的力量来完成工作，矮脚鸡，2010 年。

Ayres, Ian: Carrots and Sticks: Unlock the Power of Incentives to Get Things Done, Bantam, 2010.

Beck、Kent 和 Martin Fowler：规划极限编程，Addison-Wesley Professional，2000 年。

Beck, Kent and Martin Fowler: Planning Extreme Programming, Addison-Wesley Professional, 2000.

Beck, Kent：测试驱动开发：通过示例，Addison-Wesley Professional，2002 年。

Beck, Kent: Test Driven Development: By Example, Addison-Wesley Professional, 2002.

Benson、Jim 和 Tonianne DeMaria Barry：个人看板：映射工作 | 航海人生，创意空间独立出版平台，2011。

Benson, Jim and Tonianne DeMaria Barry: Personal Kanban: Mapping Work | Navigating Life, CreateSpace Independent Publishing Platform, 2011.

Brooks, Jr., Frederick P.：人月神话：软件工程随笔，周年纪念版，Addison-Wesley Professional，1995 年。

Brooks, Jr., Frederick P.: The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition, Addison-Wesley Professional, 1995.

Brown, Simon：开发人员的软件架构，Leanpub，2012 年。

Brown, Simon: Software Architecture for Developers, Leanpub, 2012.

Cohn, Mike：敏捷估算和规划，Prentice Hall，2005 年。

Cohn, Mike: Agile Estimating and Planning, Prentice Hall, 2005.

Derby、Esther 和 Johanna Rothman：闭门造车：伟大管理的秘密，实用书架，2005 年。

Derby, Esther and Johanna Rothman: Behind Closed Doors: Secrets of Great Management, Pragmatic Bookshelf, 2005.

Ellnestam、Ola 和 Daniel Brolund：天皇方法，曼宁出版社，2013 年。

Ellnestam, Ola and Daniel Brolund: The Mikado Method, Manning Publications, 2013.

埃里克埃文斯：领域驱动设计：应对软件核心的复杂性，Addison-Wesley Professional，2003 年。

Evans, Eric: Domain-Driven Design: Tackling Complexity in the Heart of Software, Addison-Wesley Professional, 2003.

Foote、Brian 和 Joseph Yoder：一个大泥球，第四届程序模式语言会议 (PLoP '97/EuroPLoP '97)，伊利诺伊州蒙蒂塞洛，1997 年 9 月。

Foote, Brian and Joseph Yoder: A Big Ball of Mud, Fourth Conference on Patterns Languages of Programs (PLoP ‘97/EuroPLoP ‘97), Monticello, Illinois, September 1997.

Gamma、Erich、Richard Helm、Ralph Johnson 和 John Vlissides：设计模式：可重用面向对象软件的元素，Addison-Wesley Professional，1994 年。

Gamma, Erich, Richard Helm, Ralph Johnson and John Vlissides: Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley Professional, 1994.

格拉德威尔，马尔科姆：眨眼：不假思索的思考的力量，Back Bay Books，2007 年。

Gladwell, Malcolm: Blink: The Power of Thinking Without Thinking, Back Bay Books, 2007.

Gray、Dave、Sunni Brown 和 James Macanufo：Gamestorming：A Playbook for Innovators、Rulebreakers 和 Changemakers，O'Reilly Media，2010 年。

Gray, Dave, Sunni Brown and James Macanufo: Gamestorming: A Playbook for Innovators, Rulebreakers, and Changemakers, O’Reilly Media, 2010.

Lopp, Michael：Managing Humans：软件工程经理的辛辣幽默故事，Apress，2012 年。

Lopp, Michael: Managing Humans: Biting and Humorous Tales of a Software Engineering Manager, Apress, 2012.

Osherove, Roy：给软件团队领导的笔记，Team Agile Publishing，2013 年。

Osherove, Roy: Notes to a Software Team Leader, Team Agile Publishing, 2013.

Osherove, Roy：单元测试的艺术：以 .NET 中的示例为例，Manning Publications，2013 年。

Osherove, Roy: The Art of Unit Testing: With Examples in .NET, Manning Publications, 2013.

Patterson、Kerry、Joseph Grenny、Ron McMillan 和 Al Switzler：关键对话：利害攸关时的谈话工具，第二版，麦格劳-希尔出版社，2011 年。

Patterson, Kerry, Joseph Grenny, Ron McMillan and Al Switzler: Crucial Conversations: Tools for Talking When Stakes Are High, Second Edition, McGraw-Hill, 2011.

Pink, Dan：驱动力：关于激励我们的惊人真相，Riverhead Books，2011 年。

Pink, Dan: Drive: The Surprising Truth About What Motivates Us, Riverhead Books, 2011.

Rath, Tom：StrengthsFinder 2.0，盖洛普出版社，2007 年。

Rath, Tom: StrengthsFinder 2.0, Gallup Press, 2007.

Reynolds, Garr：Presentation Zen：Presentation Design and Delivery 的简单想法，New Riders，2011 年。

Reynolds, Garr: Presentation Zen: Simple Ideas on Presentation Design and Delivery, New Riders, 2011.

Rosenberg、Marshall B. 和 Arun Gandhi：非暴力沟通：一种生活语言，Puddledancer 出版社，2003 年。

Rosenberg, Marshall B. and Arun Gandhi: Nonviolent Communication: A Language of Life, Puddledancer Press, 2003.

Spence, Gerry：如何每次争论并取胜：在家里、工作中、法庭上、任何地方、每一天，St. Martin's Griffin，1996 年。

Spence, Gerry: How to Argue & Win Every Time: At Home, At Work, In Court, Everywhere, Everyday, St. Martin’s Griffin, 1996.

Weinberg, Gerald M.：Becoming a Technical Leader，Dorset House Publishing，1986 年。

Weinberg, Gerald M.: Becoming a Technical Leader, Dorset House Publishing, 1986.

Weinberg、Gerald M 和 Daniela Weinberg：系统设计的一般原则，Dorset House Publishing，1988 年。

Weinberg, Gerald M and Daniela Weinberg: General Principles of System Design, Dorset House Publishing, 1988.

Wilde, Gerald JS：目标风险 2：安全与健康的新心理学，Pde Pubns，2001 年。

Wilde, Gerald J.S.: Target Risk 2: A New Psychology of Safety and Health, Pde Pubns, 2001.

有用的网站

Useful Websites

个人看板

Personal Kanban

收件箱归零

Inbox Zero

把事情 做好兰兹

Getting Things Done Rands

其他参考资料

Other References

Foote、Brian 和 Joseph Yoder：一个大泥球，第四届程序模式语言会议 (PLoP '97/EuroPLoP '97)，伊利诺伊州蒙蒂塞洛，1997 年 9 月。

Foote, Brian and Joseph Yoder: A Big Ball of Mud, Fourth Conference on Patterns Languages of Programs (PLoP ‘97/EuroPLoP ‘97) Monticello, Illinois, September 1997.

Linux 杂志

Linux Magazine

ACM 通讯

Communications of the ACM

关于作者

About the Author

在编写本书时，我正在 ThoughtWorks 担任顾问，在那里你会发现我领导团队并努力创造开发人员可以茁壮成长的良好环境，始终专注于为最终用户提供价值。我对平衡软件开发的人员方面以及解决技术难题的挑战和乐趣非常感兴趣。是的，我仍然写代码并且喜欢它。

When this book was being put together, I was working as a consultant for ThoughtWorks, where you would find me leading teams and striving to create great environments where developers could thrive, always focused on delivering value to end users. I have a great interest in balancing the people side to software development, as well as the challenge and enjoyment of solving hard technical problems. And yes, I still write code too and love it.

我热衷于通过使用回顾和培养个人来改进团队。我已经指导过许多开发人员担任 Tech Lead 的角色，我希望这本书能帮助您提高对 Tech Lead 的掌握程度，或者更好地为您作为 Tech Lead 的旅程做好准备。

I am passionate about improving teams through the use of Retrospectives and growing individuals. I have coached a number of developers into the role of being a Tech Lead and I hope this book helps you grow your mastery as a Tech Lead or better prepares you for the start of your journey as a Tech Lead.